Java异常处理及其应用

经常能够在代码块中看到类似的代码块。有人总喜欢在编写代码时简单快速地编写空处理器块，并“自我安慰地”宣称准备在“后期”添加恢复代码，但这个“后期”变成了“无期”。

这种做法有什么坏处？如果异常对应用程序的其他部分确实没有任何负面影响，这未尝不可。但事实往往并非如此，异常会扰乱应用程序的状态。此时，这样的代码无异于掩耳盗铃。

这种做法若影响较轻，则应用程序可能出现怪异行为。例如，应用程序设置的一个值不见了， 或 GUI 失效。若问题严重，则应用程序可能会出现重大问题，因为异常未记录原始故障点，难以处理，如重复的 NullPointerExceptions。

如果采取措施，记录了捕获的异常，则不可能遇到这个问题。实际上，除非确认异常对代码其余部分绝无影响，至少也要作记录。进一步讲，永远不要忽略问题；否则，风险很大，在后期会引发难以预料的后果。

不要使用覆盖式异常处理块

另一个危险的处理是覆盖式处理器（blanket handler）。该代码的基本结构如下：

1　　try{
2　　　//　…　
3　　}
4　　catch(Exception　e){
5　　　//　…　
6　　}

使用覆盖式异常处理块有两个前提之一：

1. 代码中只有一类问题。

这可能正确，但即便如此，也不应使用覆盖式异常处理，捕获更具体的异常形式有利物弊。

2. 单个恢复操作始终适用。

这几乎绝对错误。几乎没有哪个方法能放之四海而皆准，能应对出现的任何问题。

分析下这样编写代码将发生的情况。只要方法不断抛出预期的异常集，则一切正常。但是，如果抛出了未预料到的异常，则无法看到要采取的操作。当覆盖式处理器对新异常类执行千篇一律的任务时，只能间接看到异常的处理结果。如果代码没有打印或记录语句，则根本看不到结果。

更糟糕的是，当代码发生变化时，覆盖式处理器将继续作用于所有新异常类型，并以相同方式处理所有类型。

一般不要把特定的异常转化为更通用的异常

将特定的异常转换为更通用异常时一种错误做法。一般而言，这将取消异常起初抛出时产生的上下文，在将异常传到系统的其他位置时，将更难处理。见下例：

1　　try{
2　　　//　Error-prone　code
3　　}
4　　catch(IOException　e){
5　　　String　msg　=　"If　you　didn　’　t　have　a　problem　before,you　do　now!";
6　　　throw　new　Exception(msg);
7　　}

因为没有原始异常的信息，所以处理器块无法确定问题的起因，也不知道如何更正问题。

不要处理能够避免的异常

对于有些异常类型，实际上根本不必处理。通常运行时异常属于此类范畴。在处理空指针或者数据索引等问题时，不必求助于异常处理。