以文本方式查看主题 - 中文XML论坛 - 专业的XML技术讨论区 (http://bbs.xml.org.cn/index.asp) -- 『 Java/Eclipse 』 (http://bbs.xml.org.cn/list.asp?boardid=41) ---- [原创]java语言中异常错误恢复处理的异常类型 (http://bbs.xml.org.cn/dispbbs.asp?boardid=41&rootid=&id=67343) |
-- 作者:kelvinmok -- 发布时间:9/17/2008 5:03:00 PM -- [原创]java语言中异常错误恢复处理的异常类型 Java语言要求java程序中(无论是谁写的代码)所有抛出(throw)的异常都必须是从Throwable派生而来。当然,实际的Java编程中,由于JDK平台已经为我们设计好了非常丰富和完整的异常对象分类模型。因此,java程序员一般是不需要再重新定义自己的异常对象。而且即便是需要扩展自定义的异常对象,也往往会从Exception派生而来。所以,对于java程序员而言,它一般只需要在它的顶级函数中catch(Exception ex)就可以捕获出所有的异常对象。 所有异常对象的根基类是 Throwable ,Throwable从Object直接继承而来(这是java系统所强制要求的),并且它实现了 Serializable接口(这为所有的异常对象都能够轻松跨越Java组件系统做好了最充分的物质准备)。从Throwable直接派生出的异常类有Exception和Error 。Exception是java程序员所最熟悉的,它一般代表了真正实际意义上的异常对象的根基类。也即是说, Exception 和从它派生而来的所有异常都是应用程序能够catch到的,并且可以进行异常错误恢复处理的异常类型。而Error则表示Java系统中出现了一个非常严重的异常错误,并且这个错误可能是应用程序所不能恢复的,例如LinkageError ,或 ThreadDeath 等。 首先还是看一个例子吧!代码如下:
熟悉 java 语言的程序员朋友们,你们认为上面的程序有什么问题吗?编译能通过吗?如果不能,那么原因又是为何呢?好了,有了自己的分析和预期之后,不妨亲自动手编译一下上面的小程序,呵呵!结果确实如您所料?是的,的确是编译时报错了,错误信息如下:
上面这种编译错误信息,相信 Java 程序员肯定见过(可能还是屡见不鲜!)! 相信老练一些的 Java 程序员一定非常清楚上述编译出错的原因。那就是如错误信息中(“ must be caught ”)描述的那样, 在 Java 的异常处理模型中,要求所有被抛出的异常都必须要有对应的“异常处理模块” 。也即是说,如果你在程序中 throw 出一个异常,那么在你的程序中(函数中)就必须要 catch 这个异常(处理这个异常)。例如上面的例子中,你在第 20 行代码处,抛出了一个 Exception 类型的异常,但是在该函数中,却没有 catch 并处理掉此异常的地方。因此,这样的程序即便是能够编译通过,那么运行时也是致命的(可能导致程序的崩溃),所以, Java 语言干脆在编译时就尽可能地检查(并卡住)这种本不应该出现的错误,这无疑对提高程序的可靠性大有帮助。 但是,在 Java 语言中,这就是必须的。 如果一个函数中,它运行时可能会向上层调用者函数抛出一个异常,那么,它就必须在该函数的声明中显式的注明(采用 throws 关键字) 。还记得刚才那条编译错误信息吗?“ must be caught or declared to be thrown ”,其中“ must be caught ”上面已经解释了,而后半部分呢?“ declared to be thrown ”是指何意呢?其实指的就是“必须显式地声明某个函数可能会向外部抛出一个异常”,也即是说,如果一个函数内部,它可能抛出了一种类型的异常,但该函数内部并不想(或不宜) catch 并处理这种类型的异常,此时,它就必须使用 throws 关键字来声明该函数可能会向外部抛出一个异常,以便于该函数的调用者知晓并能够及时处理这种类型的异常。下面列出了这几种情况的比较,代码如下:
不知上面几个有联系的示例是否能够给大家带来“豁然开朗”的感觉,坦率的说, Java 提供的异常处理模型并不复杂,相信太多太多 Java 程序员有着比我更深刻的认识。最后,补充一种例外情况,请看如下代码:
朋友们!上面的程序能被编译通过吗?注意,按照刚才上面所总结出的规律:在 Java 的异常处理模型中,要求所有被抛出的异常都必须要有对应的 catch 块!那么上面的程序肯定不能被编译通过,因为 Error 和 Exception 都是从 Throwable 直接派生而来,而 test 函数声明了它可能抛出 Error 类型的异常,但在 main 函数中却并没有 catch(Error) 或 catch(Throwable) 块,所以它理当是会编译出错的!真的吗?不妨试试!呵呵!结果并非我们之预料,而它恰恰是正确编译通过了。为何? WHY ? WHY ? 其实,原因很简单,那就是因为 Error 异常的特殊性。 Java 异常处理模型中规定: Error 和从它派生而来的所有异常,都表示系统中出现了一个非常严重的异常错误,并且这个错误可能是应用程序所不能恢复的 (其实这在前面的内容中已提到过)。因此,如果系统中真的出现了一个 Error 类型的异常,那么则表明,系统已处于崩溃不可恢复的状态中,此时,作为编写 Java 应用程序的你,已经是没有必要(也没能力)来处理此等异常错误。所以, javac 编译器就没有必要来保证:“在编译时,所有的 Error 异常都有其对应的错误处理模块”。当然, Error 类型的异常一般都是由系统遇到致命的错误时所抛出的,它最后也由 Java 虚拟机所处理。而作为 Java 程序员的你,可能永远也不会考虑抛出一个 Error 类型的异常。因此 Error 是一个特例情况! 特别关注一下 RuntimeException 上面刚刚讨论了一下 Error 类型的异常处理情况, Java 程序员一般无须关注它(处理这种异常)。另外,其实在 Exception 类型的异常对象中,也存在一种比较特别的“异常”类型,那就是 RuntimeException ,虽然它是直接从 Exception 派生而来,但是 Java 编译器( javac )对 RuntimeException 却是特殊待遇,而且是照顾有加。不信,看看下面的两个示例吧!代码如下: public class Trans { static void test() {
public class Trans { static void test() {
对上面两个相当类似的程序, javac 编译时却遭遇了两种截然不同的处理,按理说,第 2 个示例程序也应该像第 1 个示例程序那样,编译时报错!但是 javac 编译它时,却例外地让它通过它,而且在运行时, java 虚拟机也捕获到了这个异常,并且会在 console 打印出详细的异常信息。运行结果如下:
为什么对于 RuntimeException 类型的异常(以及从它派生而出的异常类型), javac 和 java 虚拟机都特殊处理呢?要知道,这可是与“ Java 异常处理模型更严谨和更安全”的设计原则相抵触的呀!究竟是为何呢?这简直让人不法理解呀! 只不过, Java 语言中, RuntimeException 被统一纳入到了 Java 语言和 JDK 的规范之中。请看如下代码,来验证一下我们的理解!
运行结果如下:
又如下面的例子,也会产生一个 RuntimeException ,代码如下:
所以,针对 RuntimeException 类型的异常, javac 是无法通过编译时的静态语法检测来判断到底哪些函数(或哪些区域的代码)可能抛出这类异常(这完全取决于运行时状态,或者说运行态所决定的),也正因为如此, Java 异常处理模型中的“ must be caught or declared to be thrown ”规则也不适用于 RuntimeException (所以才有前面所提到过的奇怪编译现象,这也属于特殊规则吧)。但是, Java 虚拟机却需要有效地捕获并处理此类异常。当然, RuntimeException 也可以被程序员显式地抛出,而且为了程序的可靠性,对一些可能出现“运行时异常( RuntimeException )”的代码区域,程序员最好能够及时地处理这些意外的异常,也即通过 catch(RuntimeExcetion) 或 catch(Exception) 来捕获它们。如下面的示例程序,代码如下:
|
W 3 C h i n a ( since 2003 ) 旗 下 站 点 苏ICP备05006046号《全国人大常委会关于维护互联网安全的决定》《计算机信息网络国际联网安全保护管理办法》 |
108.398ms |