网站开发培训费用,深圳58网站建设,网站建设与运营实践考试,陕西网站制作公司排名异常处理是java语言的重要特性之一#xff0c;《Three Rules for effective Exception Handling》一文中是这么解释的#xff1a;它主要帮助我们在debug的过程中解决下面的三个问题。什么出错了哪里出错了为什么出错java语言可以说是提供了过于完善的异常处理机制#xff0c…异常处理是java语言的重要特性之一《Three Rules for effective Exception Handling》一文中是这么解释的它主要帮助我们在debug的过程中解决下面的三个问题。什么出错了哪里出错了为什么出错java语言可以说是提供了过于完善的异常处理机制以致于后来《Thinking in java》的作者Bruce Eckel都专门对他进行了论述。java中的异常机制包括Error和Exception两个部分。他们都继承自一个共同的基类Throwable。Error属于JVM运行中发生的一些错误虽然并不属于开发人员的范畴但是有些Error还是由代码引起的比如StackOverflowError经常由递归操作引起这种错误就是告诉开发者你一般无法挽救只能靠JVM。而Exception假设程序员会去处理这些异常比如数据库连接出了异常那么我们可以处理这个异常并且重新连接等。Exception分为两种检查类型(checked)和未检查类型(unchecked)。检查类型的异常就是说要程序员明确的去声明或者用try..catch语句来处理的异常而非检查类型的异常则没有这些限制比如我们常见的NullPointerException 就是非检查类型的他继承自RuntimeException。java是目前主流编程语言中唯一一个推崇使用检查类型异常的至少sun是这样的。关于使用checked还是unchecked异常的论战一直很激烈。下面是一张java语言中异常的类关系图。基本使用我们在使用java的一些文件或者数据库操作的时候已经接触过一些异常了比如IOException、SQLException等这些方法被声明可能会抛出某种异常因此我们需要对其进行捕获处理。这就需要基本的try..catch语句了。下图就是我们经常写的一个基本结构。try语句块中写可能会抛出异常的代码之后在catch语句块中进行捕获。我们看到catch的参数写的是一个Exception对象这就意味着这个语句块可以捕获所有的检查类型的异常(虽然这并不是一种好的写法稍后讨论)finally总是会保证在最后执行一般我们在里面处理一些清理的工作比如关闭文件流或者数据库网络等操作。当然上面的语句块结构是灵活的但是try是必须有的catch和finally两者至少有一个当然catche的数量可以有多个。有时候try语句块中可能抛出多种类型的异常这个时候我们可以写多个catch语句来捕获不同类型的异常一个比较好的写法如下try{// ..invoke some methods that may throw exceptions}catch(ExceptionType1 e){//...handle exception}catch(ExceptionType2 e){//...handle exception}catch(Exception e){//...handle exception}finally{//..do some cleaning :close the file db etc.}当异常不满足前两个type的时候exception会将异常捕获。我们发现这个写法比较类似switch case的结构控制语句但实际上一旦某个catch得到匹配后其他的就不会就匹配了有点像加了break的case。有一点需要注意catch(Exception)一定要写在最后面catch是顺序匹配的后面匹配Exception的子类编译器就会报错。初次学习try..catch总会被其吸引所以大量的使用这种结果以达到某种“鲁棒性”。(这语句也是程序员表白的最爱)。但try语句实际上执行的时候会导致栈操作。即要保存整个方法的调用路径这势必会使得程序变慢。fillInStackTrace()是Throwable的一个方法用来执行栈的操作他是线程同步的本身也很耗时。这里问题在StackOverFlow上曾经有过一段非常经典的讨论原文。 的确当我们在try中什么都不做或者只执行一个类似加法的简单调用那么其执行效率和goto这样的控制语句是几乎一样的。但是谁会写这样的代码呢总之不要总是试图通过try catch来控制程序的结构无论从效率还是代码的可读性上都不好。try catch好的一面try catch虽然不推荐用于程序结构的控制但是也具有重要的意义其设计的一个好处就是开发人员可以把一件事情当做事务来处理事务也是数据库中重要的概念举个例子比如完成订单的这个事务其中包括了一个动作序列包括用户提交订单商品出库关联等。当这个序列中某一个动作执行失败的时候数据统一恢复到一个正常的点这样就不会出现你付完了帐商品却没有给你的情况。我们在try语句块中就像执行一个事务一样当出现了异常就会在catch中得到统一的处理保证数据的完整无损。其实很多不好的代码也是因为没有好好利用catch语句的语言导致很多异常就被淹没了这个后面介绍。定制详细的异常我们可以自己定义异常以捕获处理某个具体的例子。创建自己的异常类可以直接继承Exception或者RuntimeException。区别是前者是简称类型的而后者为检查类型异常。Sun官方力挺传统的观点他建议开发者都是用检查类型的异常即你一定要去处理的异常。下面是定义的一个简单的异常类.public class SimpleException extends Exception{SimpleException(){}SimpleException(String info){super(info);}}我们覆写了两个构造方法这是有意义的。通过传递字符串参数我们创建一个异常对象的时候可以记录下详细的信息这样这个异常被捕获的时候就会显示我们之前定义的详细信息。比如用下面的代码测试一下我们定义的异常类public class test {public void fun() throws SimpleException{throw new SimpleException(throwing from fun);}public static void main(String[] args) {Test t new Test();try{t.fun();}catch(SimpleException e){e.printStackTrace();}}}运行就会得到下面的结果 printStackTrace是打印调用栈的方法他有三个重载方法默认的是将信息输出到System.err。这样我们就可以清晰的看到方法调用的过程有点像操作系统中的中断保护现场。SimpleException: throwing from funat Test.fun(Test.java:4)at Test.main(Test.java:9)略微麻烦的语法我们自己实现的异常有时候会用到继承这些特性在异常继承的时候有一些限制。那就是子类不能抛出基类或所实现的接口中没有抛出的异常.比如有如下的接口public interface InterfaceA {public void f() throws IOException;}我们的Test类实现这个接口那么Test的f方法要么不抛出异常要么只能抛出IOException其实关于这里还有更琐碎的规矩详细可以参考《Java Puzzlers》第37个谜题。所以这和传统的继承和实现接口正好相反面向对象的继承是扩大化而这正好是缩小了。关于checked和unchecked的论战传统的观点里sun认为因为 Java 语言并不要求方法捕获或者指定运行时异常因此编写只抛出运行时异常的代码或者使得他们的所有异常子类都继承自RuntimeException对于程序员来说是有吸引力的。这些编程捷径都允许程序员编写 Java 代码而不会受到来自编译器的所有挑剔性错误的干扰并且不用去指定或者捕获任何异常。 尽管对于程序员来说这似乎比较方便但是它回避了 Java 的捕获或者指定要求的意图并且对于那些使用您提供的类的程序员可能会导致问题。他强调尽量不使用unchecked异常。但《Thinking in java》的作者Eckel却改变了自己的想法 他在自己博客上的一篇文章(这篇文章很好表达也很简单)专门列举了使用checked异常的弊端。他指出正式检查类型让导致了很多的异常不能被程序员发现。开发人员有更大的自由去决定是不是要处理一个异常。即使忘记处理了某个异常他也会在某个地方抛出来被发现而不至于丢失。checked异常使得代码的可读性变差并且正在暗暗的鼓励人们去淹没异常。现在很多IDE都在提醒我们某个方法要跑出异常然后甚至自动帮我们生成catch或者throw。这是非常可怕的行为这导致了我们很多catch语句里面什么都没有就像一个陷阱一样。checked异常带来的另一个问题是代码的难维护性因为要在方法声明上加上throws如果方法的实现发生了某个变化有了新的异常那么我们不得不去修改方法的声明。还有一点不好的就是不能明确的暴露异常的特征。比如我们登录成绩系统的时候如果用户名注册我们可能期待一个NoSuchStudentException但是实际看到的可能是一个SQLException。《Effective java》中第 43 条抛出与抽象相适应的异常。讲的就是这个原则即抛出的异常应该是和抽象的概念一致的比如我们在一个系统无论遇到什么具体的问题但是大部分我们看到的都只是SQLException而已。关于如何选择Bloch的建议是为可恢复的条件使用检查型异常为编程错误使用运行时异常。我的感觉是选择检查的异常就一定要”处理“,当然此处的处理一定是真正的处理而不是空写一个catch语句而已。不知道未来的java会怎样对待checked和unchecked毕竟现在java是唯一一个支持检查异常的主流编程语言了。好的原则Fail Fast:就是要尽早的抛出异常这样有有助于更加精确的定位出错的地点和原因。这个也比较好理解比如用户名字不合法的时候马上抛出UserNameIllegalException如果没有及时抛出异常那么不合法的名字可能会导致一个SQLException,但是程序报给你一个SQLException,你却很难直接得知一定是用户名不合法造成的。Fail Fast这种思想在java实现ArrayList的机制中也有很好的体现。Catch late:不要在方法内部过早的处理异常特别是什么也不做的处理那就更加的可怕了。因为如果“无作为”的处理很可能导致后面继续出现新的异常(比如错误的用户名会引发后面一些列错误程序还不能处理好错误的用户名后面的就更处理不了了)这就给调试增加了很大的困难。一个好的经验是将异常处理交给调用者方法只在及时的地方抛出异常技术上实现的方式就是给方法声明throws标出所有可能要抛出的异常。Doc文档的重要性特别是非检查的异常一定要在文档中注明。异常处理是java非常重要的特性上面是一些关于异常使用的讨论当然更多知识还是需要实践中发现。
