li295214001的专栏

一、Java中异常概述1.1Java异常结构

Throwable可以用来表示任何可以被作为异常抛出的类。Throwable对象派生出两种类型:Error和Exception,前者用来表示编译时和系统错误,程序员往往不必关心;后者是可以被抛出的基本类型,需要程序员关注。RuntimeException是Exception的派生类,不同点将在2.2与2.3小结中描述。

Java的异常(Exception)按照编译器检查方式又可以分为检查型异常(CheckedException)和非检查型异常(UncheckedException)。

1.2检查型异常(CheckedException)

在Java中所有不是RuntimeException派生的Exception都是检查型异常。当函数中存在抛出检查型异常的操作时该函数的函数声明中必须包含throws语句。调用改函数的函数也必须对该异常进行处理,如不进行处理则必须在调用函数上声明throws语句。

检查型异常是JAVA首创的,在编译期对异常的处理有强制性的要求。在JDK代码中大量的异常属于检查型异常,包括IOException,SQLException等等。

1.3非检查型异常(UncheckedException)

在Java中所有RuntimeException的派生类都是非检查型异常,与检查型异常相对抛出非检查型异常可以不在函数声明中添加throws语句,调用函数上也不需要强制处理。

常见的NullPointException,ClassCastException是常见的非检查型异常。非检查型异常 可以不使用try…catch进行处理,但是如果有异常产生,则异常将由JVM进行处理。对于RuntimeException的子类最好也使用异常处理机制。虽然RuntimeException的异常可以不使用try…catch进行处理,但是如果一旦发生异常,则肯定会导致程序中断执行,所以,为了保证程序再出错后依然可以执行,在开发代码时最好使用try…catch的异常处理机制进行处理。

1.4异常的关键字

Java异常处理涉及到五个关键字,分别是:try、catch、finally、throw、throws

五个关键字的相关语法略。

二、异常处理方式2.1异常链

在JDK1.4以后版本中,Throwable类支持异常链机制。Throwable 包含了其线程创建时线程执行堆栈的快照。它还包含了给出有关错误更多信息的消息字符串。最后,它还可以包含 cause(原因):另一个导致此 throwable 抛出的 throwable。它也称为异常链 设施,因为 cause 自身也会有 cause,依此类推,就形成了异常链,每个异常都是由另一个异常引起的。

通俗的说,异常链就是把原始的异常包装为新的异常类,,并在新的异常类中封装了原始异常类,这样做的目的在于找到异常的根本原因。

2.2异常的转译

异常转译就是将一种异常转换另一种新的异常并且再抛出的过程,异常转译的目的是将系统中出现的不同类型的异常进行型别的统一,以便于异常的统一处理。

绝大多数情况下转译出的“结果异常”类型都是自定义异常,并且在异常转译过程中需要将“原始异常”放置在异常链中。

2.3自定义异常

自定义异常就是自写的继承了Exception或RuntimeException的异常类。实现自定义异常的目的大致可分为以下三种:

1. 使用统一的类型标识多种不同型别的异常。

2. 在产生异常时更好的进行信息传递。常见的手段是在异常中定义异常码,异常信息,环境对象等字段。

3. 将检查型异常转换为非检查型异常。

三异常处理3.1关于检查型异常与非检查型异常的争论

在实际编程过程中使用检查型异常与非检查型异常的时机从JAVA语言产生的那一天开始就已经产生。

最为官方的说法可以参考Java最核心设计者之一JOSHUA BLOCH的《Effective Java》异常使用章节,他的主张是:对可恢复的情况使用检查型异常,对编程错误使用运行时异常。

虽然上述说法有着“皇家血统”但事实上在我看来Java的检查型异常是一个非常失败的作品,因为检查型异常具有超强的“污染性”,它的出现所带来的麻烦远比好处要多得多。我的观点是:几乎在所有的情况下都不应当使用检查型异常。当遇到检查型异常无法处理的情况时,应该使用异常转译转换为非检查型异常再抛出。我非常兴奋的看到在Think in Java 4th Edition上作者对这样的观点进行了详细的描述。

Java创造检查型异常的初衷是在编译期强制程序员对异常情况进行处理,从而使得程序更加的强壮可靠,可是Java的作者忘记了:好的程序设计语言能帮助程序员写出好程序,但无论那种语言都避免不了程序员用它写出坏程序。

对于异常处理的关键点并不在于是在编译期还是运行期对异常进行检查,而在于异常一定要检查并且需要建立统一的、一致的异常检查与处理模型。

3.2我的异常处理原则

1. 仅处理当前可处理的异常。

2. 对所有的检查型异常使用异常转译。

3. 所有的自定义异常都是非检查型异常。

4. 异常流程与正常流程进行分离,并尽可能的统一处理。

5. 在非异常处理模块的catch块中尽可能不记日志。

6. 除非是进行资源释放操作,否则catch块不应为空或者出现e.printTrace

7. finally块中不能出现复杂的操作,且不可以抛出异常,也不可以出现return。

3.3我处理异常的一般方式

1. 将throw语句视为异常流程的起点,将Exception对象视作正常流程向异常流程跃迁过程中的数据载体。

2. 建立统一的自定义异常类型,用以包装所有检查型异常。

3. 大多数情况下仅在程序的主干上建立唯一的异常捕获点,并在这个点上对接收到的异常进行处理。

今天又是美好的一天,我要展示出我优秀的一面。不必一味讨好别人

li295214001的专栏

相关文章:

你感兴趣的文章:

标签云: