java的基本理念是“结构不佳的代码不能运行”。
1.概念
“异常”这个词有“我对此感到意外”的意思。问题出现了,你也许不清楚该如何处理,但你的确知道不应该置之不理;你要停下来,看看是不是有别人或在别的地方,能够处理这个问题。只是在当前的环境中还没有足够的信息来解决这个问题,所以就把这个问题提交到一个更高级别的环境中,在这里将作出正确的决定。
使用异常所带来的另一个相当明显的好处是,它往往能够降低错误处理代码的复杂度。如果不使用异常,那么就必须检查特定的错误,并在程序中的许多地方去处理它。而如果使用异常,那就不必在方法调用处进行检查,因为异常机制将保证能够捕获这个错误。并且,只需在一个地方处理错误,即所谓的异常处理程序中。这种方式不仅节省代码,而且把“描述在正常执行过程中做什么事”的代码和“出了问题怎么办”的代码相分离。总之,与以前的错误处理
方法相比,异常机制使代码的阅读、编写和调试工作更加井井有条。
2.基本异常
异常情形( exceptional condition)是指阻止当前方法或作用域继续执行的问题。把异常情形与普通问题相区分很重要,所谓的普通问题是指,在当前环境下能得到足够的信息,总能处理这个错误。而对于异常情形,就不能继续下去了,因为在当前环境下无法获得必要的信息来解决问题。你所能做的就是从当前环境跳出,并且把问题提交给上一级环境。这就是抛出异常时所发生的事情。
当抛出异常后,有几件事会随之发生。首先,同Java中其他对象的创建一样,将使用new在堆上创建异常对象。然后,当前的执行路径(它不能继续下去了)被终止,并且从当前坏境中弹出对异常对象的引用。此时,异常处理机制接管程序,并开始寻找一个恰当的地方来继续执行程序。这个恰当的地方就是异常处理程序,它的任务是将程序从错误状态中恢复,以使程序能要么换一种方式运行,要么继续运行下去。
异常使得我们可以将每件事都当作一个事务来考虑,而异常可以看护着这些事务的底线。“事务的基本保障是我们所需的在分布式计算中的异常处理。事务是计算机中的合同法,如果出了什么问题,我们只需要放弃整个计算。”我们还可以将异常看作是一种内建的恢复（undo)系统,因为(在细心使用的情况下)我们在程序中可以拥有各种不同的恢复点。如果程序的某部分失败了,异常将“恢复”到程序中某个已知的稳定点上。
异常最重要的方面之一就是如果发生问题,它们将不允许程序沿着其正常的路径继续走下去。异常允许我们(如果没有其他手段)强制程序停止运行,并告诉我们出现了什么问题,或者(理想状态下)强制程序处理问题,并返回到稳定状态。
异常参数
与使用Java中的其他对象一样,我们总是用new在堆上创建异常对象,这也伴随着存储空间的分配和构造器的调用。所有标准异常类都有两个构造器:一个是默认构造器;另一个是接受字符串作为参数,以便能把相关信息放入异常对象的构造器:
throw new NullPointer Exception(“t=null”);
3.捕获异常
要明白异常是如何被捕获的,必须首先理解监控区域( guarded region)的概念。它是一段可能产生异常的代码,并且后面跟着处理这些异常的代码。
3.1try块
如果在方法内部抛出了异常(或者在方法内部调用的其他方法抛出了异常),这个方法将在抛出异常的过程中结束。要是不希望方法就此结束,可以在方法内设置一个特殊的块来捕获异常。因为在这个块里“尝试”各种(可能产生异常的)方法调用,所以称为try块。它是跟在try关键字之后的普通程序块:
try{
// Code that might generate exceptions
}对于不支持异常处理的程序语言,要想仔细检査错误,就得在每个方法调用的前后加上设置和错误检查的代码,甚至在每次调用同一方法时也得这么做。有了异常处理机制,可以把所有动作都放在try块里,然后只需在一个地方就可以捕获所有异常。这意味着代码将更容易编写和阅读,因为完成任务的代码没有与错误检查的代码混在一起。
3.2异常处理程序
当然,抛出的异常必须在某处得到处理。这个“地点”就是异常处理程序,而且针对每个要捕获的异常,得准备相应的处理程序。异常处理程序紧跟在try块之后,以关键字 catch表示:
try {
//Code that might generate exceptions
} catch(Type1 id1) {
// Handle exceptions of Type1
} catch(Type2 id2){
//Handle exceptions of Type2
} catch(Type3 id3){
//Handle exceptions of type3
}
// etc
每个 catch子句(异常处理程序)看起来就像是接收一个且仅接收一个特殊类型的参数的方法。可以在处理程序的内部使用标识符(id1,id2等等),这与方法参数的使用很相似。有时可能用不到标识符,因为异常的类型已经给了你足够的信息来对异常进行处理,但标识符并不可以省略。
异常处理程序必须紧跟在try块之后。当异常被抛出时,异常处理机制将负责搜寻参数与异常类型相匹配的第一个处理程序。然后进入 catch子句执行,此时认为异常得到了处理。一旦catch子句结束,则处理程序的查找过程结束。
注意,只有匹配的 catch子句才能得到执行;这与switch语句不同, switch语句需要在每一个case后面跟一个 break,以避免执行后续的case子句。注意在try块的内部,许多不同的方法调用可能会产生类型相同的异常,而你只需要提供一个针对此类型的异常处理程序。
终止与恢复
异常处理理论上有两种基本模型。Java支持终止模型(它是Java和C++所支持的模型)。在这种模型中,将假设错误非常关键,以至于程序无法返回到异常发生的地方继续执行。一旦异常被抛出,就表明错误已无法挽回,也不能回来继续执行。
另一种称为恢复模型。意思是异常处理程序的工作是修正错误,然后重新尝试调用出问题的方法,并认为第二次能成功。对于恢复模型,通常希望异常被处理之后能继续执行程序。如果想要用Java实现类似恢复的行为,那么在遇见错误时就不能抛出异常,而是调用方法来修正该错误。或者,把try块放在 while循环里,这样就不断地进入try块,直到得到满意的结果。
4.创建自定义异常
不必拘泥于Java中已有的异常类型。Java提供的异常体系不可能预见所有的希望加以报告的错误,所以可以自己定义异常类来表示程序中可能会遇到的特定问题。要自己定义异常类,必须从已有的异常类继承,最好是选择意思相近的异常类继承(不过这样的异常并不容易找)。建立新的异常类型最简单的方法就是让编译器为你产生默认构造器,
所以这几乎不用写多少代码。
4.1异常与记录日志
你可能还想使用 java util. logging工具将输出记录到日志中。
静态的 Logger. geLogger()方法创建了一个 String参数相关联的 Logger对象(通常与错误相关的包名和类名),这个 Logger对象会将其输出发送到 System.err。向 Logger写入的最简单方式就是直接调用与日志记录消息的级别相关联的方法,这里使用的是 severe()。
为了产生日志记录消息,我们欲获取异常抛出处的栈轨迹,但是 printStackTrace()不会默认地产生字符串。为了获
取字符串,我们需要使用重载的 printStackTrace()方法,它接受一个 Java.Io.PrintWriter对象作为参数。如果我们将一个java.io.StringWriter对象传递给这个Printwriter的构造器,那么通过调用 toString()方法,就可以将输出抽取为一个 String。
尽管由于 LoggingException将所有记录日志的基础设施都构建在异常自身中,使得它所使用的方式非常方便,并因此不需要客户端程序员的干预就可以自动运行,但是更常见的情形是我们需要捕获和记录其他人编写的异常,因此我们必须在异常处理程序中生成日志消息。
5.异常说明
异常说明使用了附加的关键字 throws,后面接一个所有潜在异常类型的列表,所以方法定义可能看起来像这样:
但是,要是这样写:
void f() throws Toobig, TooSmall, Divzero { //…
就表示此方法不会抛出任何异常(除了从 Runtimeexception继承的异常,它们可以在没有异常
void f(){ //…
说明的情况下被抛出,这些将在后面进行讨论)。
代码必须与异常说明保持一致。如果方法里的代码产生了异常却没有进行处理,编译器会发现这个问题并提醒你:要么处理这个异常,要么就在异常说明中表明此方法将产生异常。通过这种自顶向下强制执行的异常说明机制,Java在编译时就可以保证一定水平的异常正确性。
不过还是有个能“作弊”的地方:可以声明方法将抛出异常,实际上却不抛出。编译器相信了这个声明,并强制此方法的用户像真的抛出异常那样使用这个方法。这样做的好处是,为异常先占个位子,以后就可以抛出这种异常而不用修改已有的代码。在定义抽象基类和接口时这种能力很重要,这样派生类或接口实现就能够抛出这些预先声明的异常。这种在编译时被强制检查的异常称为被检查的异常。
6.捕获所有异常
可以只写一个异常处理程序来捕获所有类型的异常。通过捕获异常类型的基类 Exception,就可以做到这一点(事实上还有其他的基类,但 Exception是同编程活动相关的基类)
catch(Exception e){
System. out. println(“Caught an exception”)；
}
这将捕获所有异常,所以最好把它放在处理程序列表的末尾,以防它抢在其他处理程序之前先把异常捕获了。
因为 Exception是与编程有关的所有异常类的基类,所以它不会含有太多具体的信息,不过可以调用它从其基类 Throwable继承的方法:
String getMessage()
String getLocalizedMessage()
用来获取详细信息,或用本地语言表示的详细信息。
6.1栈轨迹
printStackTrace()方法所提供的信息可以通过 getStackTrace()方法来直接访问,这个方法将返回一个由栈轨迹中的元素所构成的数组,其中每一个元素都表示栈中的一桢。元素0是栈顶元素,并且是调用序列中的最后一个方法调用(这个 Throwable被创建和抛出之处)。数组中的最后一个元素和栈底是调用序列中的第一个方法调用。
6.2重新抛出异常
有时希望把刚捕获的异常重新抛出,尤其是在使用 Exception捕获所有异常的时候。既然已经得到了对当前异常对象的引用,可以直接把它重新抛出:
catch(Exception e){
System. out. println(“An exception was thrown “);
throw e;
}
重抛异常会把异常抛给上一级环境中的异常处理程序,同一个try块的后续 catch子句将被忽略。此外,异常对象的所有信息都得以保持,所以高一级环境中捕获此异常的处理程序可以从这个异常对象中得到所有信息。
如果只是把当前异常对象重新抛出,那么 printstacktrace()方法显示的将是原来异常抛出点的调用栈信息,而并非重新抛出点的信息。要想更新这个信息,可以调用 fillInStackTrace()方法,这将返回一个 Throwable对象,它是通过把当前调用栈信息填入原来那个异常对象而建立的。
6.3异常链
常常会想要在捕获一个异常后抛出另一个异常,并且希望把原始异常的信息保存下来,这被称为异常链。在JDK1.4以前,程序员必须自己编写代码来保存原始异常的信息。现在所有Throwable的子类在构造器中都可以接受一个 cause(因由)对象作为参数。这个 cause就用来表示原始异常,这样通过把原始异常传递给新的异常,使得即使在当前位置创建并抛出了新的异常,也能通过这个异常链追踪到异常最初发生的位置。
有趣的是,在 Throwable的子类中,只有三种基本的异常类提供了带caue参数的构造器。它们是Error(用于Java虚拟机报告系统错误)、 Exception以及 Runtimeexception。如果要把其他类型的异常链接起来,应该使用 initCause方法而不是构造器。
7.java标准异常
Throwable这个Java类被用来表示任何可以作为异常被抛出的类。 Throwable对象可分为两种类型(指从 Throwable继承而得到的类型): Error用来表示编译时和系统错误(除特殊情况外,一般不用你关心); Exception是可以被抛出的基本类型,在Java类库、用户方法以及运行时故障中都可能抛出 Exception型异常。所以Java程序员关心的基类型通常是 Exception。
7.1特例：RuntimeException
属于运行时异常的类型有很多,它们会自动被Java虚拟机抛出,所以不必在异常说明中把它们列出来。这些异常都是从 Runtimeexception类继承而来,所以既体现了继承的优点,使用起来也很方便。这构成了一组具有相同特征和行为的异常类型。并且,也不再需要在异常说明中声明方法将抛出 Runtimeexception类型的异常(或者任何从 Runtimeexception继承的异常),它们也被称为“不受检查异常”。这种异常属于错误,将被自动捕获,就不用你亲自动手了。要是自己去检查 Runtimeexception的话,代码就显得太混乱了。不过尽管通常不用捕获
Runtimeexception异常,但还是可以在代码中抛出 Runtimeexception类型的异常。
可能读者已经发现, Runtimeexception(或任何从它继承的异常)是一个特例。对于这种异常类型,编译器不需要异常说明,其输出被报告给了 System. err：
Exception in thread”main”java. lang Runt imeexception: From f()
at Nevercaught. f( Never Caught. java: 7)
at Never Caught. g(Never Caught. java: 10)
at Never Caught. main(Nevercaught java: 13)
所以答案是:如果 Runtimeexception没有被捕获而直达 main(),那么在程序退出前将调用异常的 printstacktrace()方法。
请务必记住:只能在代码中忽略 Runtimeexception(及其子类)类型的异常,其他类型异常的处理都是由编译器强制实施的。究其原因, Runtimeexception代表的是编程错误:
1)无法预料的错误。比如从你控制范围之外传递进来的null引用。
2)作为程序员,应该在代码中进行检查的错误。(比如对于 ArraylndexOutOfBoundsException,就得注意一下数组的大小了。)在一个地方发生的异常,常常会在另一个地方导致错误。
8.使用finally进行清理
对于一些代码,可能会希望无论try块中的异常是否抛出,它们都能得到执行。这通常适用于内存回收之外的情况(因为回收由垃圾回收器完成)。为了达到这个效果,可以在异常处理程序后面加上finally子句。
8.1finally用来做什么
对于没有垃圾回收和析构函数自动调用机制的语言来说, finally非常重要。它能使程序员保证:无论try块里发生了什么,内存总能得到释放。但Java有垃圾回收机制,所以内存释放不再是问题。而且,Java也没有析构函数可供调用。
那么,Java在什么情况下才能用到 finally呢?当要把除内存之外的资源恢复到它们的初始状态时,就要用到 finally子句。
当涉及break和continue语句的时候，finally字句也会得到执行，注意，如果把finally字句和带标签的break及continue配合使用，在java里就没必要使用goto语句了。
8.2在return中使用finally
因为finally子句总是会执行的，所以在一个方法中，可以从多个节点返回，并且可以保证终于的清理工作仍旧会执行。
8.3缺憾：异常丢失
异常作为程序出错的标志，绝不应该被忽略，但他还是有可能被轻易地忽略。
9.异常的限制
当覆盖方法的时候,只能抛出在基类方法的异常说明里列出的那些异常。这个限制很有用,因为这意味着,当基类使用的代码应用到其派生类对象的时候,一样能够工作(当然,这是面向对象的基本概念),异常也不例外。
异常限制对构造器不起作用。派生类构造器不能捕获基类构造器抛出的异常。
尽管在继承过程中,编译器会对异常说明做强制要求,但异常说明本身并不属于方法类型的一部分,方法类型是由方法的名字与参数的类型组成的。因此,不能基于异常说明来重载方法。此外,一个出现在基类方法的异常说明中的异常,不一定会出现在派生类方法的异常说明里。这点同继承的规则明显不同,在继承中,基类的方法必须出现在派生类里,换句话说,在继承和覆盖的过程中,某个特定方法的“异常说明的接口”不是变大了而是变小了—这恰好和类接口在继承时的情形相反。
10.构造器
有一点很重要,即你要时刻询问自己“如果异常发生了,所有东西能被正确的清理吗?”尽管大多数情况下是非常安全的,但涉及构造器时,问题就出现了。构造器会把对象设置成安全的初始状态,但还会有别的动作,比如打开一个文件,这样的动作只有在对象使用完毕并且用户调用了特殊的清理方法之后才能得以清理。如果在构造器内抛出了异常,这些清理行为也许就不能正常工作了。这意味着在编写构造器时要格外细心。
11.异常匹配
抛出异常的时候,异常处理系统会按照代码的书写顺序找出“最近”的处理程序。找到匹配的处理程序之后,它就认为异常将得到处理,然后就不再继续查找。查找的时候并不要求抛出的异常同处理程序所声明的异常完全匹配。派生类的对象也可以匹配其基类的处理程序。
12.其他可选方式
异常处理系统就像一个活门( trap door),使你能放弃程序的正常执行序列。当“异常情形”发生的时候,正常的执行已变得不可能或者不需要了,这时就要用到这个“活门”。异常代表了当前方法不能继续执行的情形。开发异常处理系统的原因是,如果为每个方法所有可能发生的错误都进行处理的话,任务就显得过于繁重了,程序员也不愿意这么做。结果常常是将错误忽略。应该注意到,开发异常处理的初衷是为了方便程序员处理错误。
异常处理的一个重要原则是“只有在你知道如何处理的情况下才捕获异常”。实际上,异常处理的一个重要目标就是把错误处理的代码同错误发生的地点相分离。这使你能在一段代码中专注于要完成的事情,至于如何处理错误,则放在另一段代码中完成。这样以来,主干代码就不会与错误处理逻辑混在一起,也更容易理解和维护。通过允许一个处理程序去处理多个出错点,异常处理还使得错误处理代码的数量趋向于减少。
“被检查的异常”使这个问题变得有些复杂,因为它们强制你在可能还没准备好处理错误的时候被迫加上 catch子句,这就导致了吞食则有害( harmful if swallowed)的问题。
程序员们只做最简单的事情,常常是无意中“吞食”了异常;然而一旦这么做,虽然能通过编译,但除非你记得复查并改正代码,否则异常将会丢失。异常确实发生了,但“吞食”后它却完全消失了。因为编译器强迫你立刻写代码来
处理异常,所以这种看起来最简单的方法,却可能是最糟糕的做法。
13.异常只用指南
应该在下列情况下使用异常:
1)在恰当的级别处理问题。(在知道该如何处理的情况下才捕获异常。)
2)解决问题并且重新调用产生异常的方法。
3)进行少许修补,然后绕过异常发生的地方继续执行。
4)用别的数据进行计算,以代替方法预计会返回的值。
5)把当前运行环境下能做的事情尽量做完,然后把相同的异常重抛到更高层
6)把当前运行环境下能做的事情尽量做完,然后把不同的异常抛到更高层。
7)终止程序。
8进行简化。(如果你的异常模式使问题变得太复杂,那用起来会非常痛苦也很烦人。)
9)让类库和程序更安全。(这既是在为调试做短期投资,也是在为程序的健壮性做长期投资。)