使用异常的优势
现在你知道了异常是什么，并且知道怎么使用它们，现在是时候讨论一下在你的程序中使用异常会有什么好处了。
优势1：隔离错误处理代码和常规代码
Exception提供了一种方法，把意外发生时的细节从程序主逻辑中隔离开来。在传统的编程中，错误的检测、报告和处理通常会导致像意大利面条那么混乱的代码。例如，请看下面的伪码，它把整个文件读入内存：
readFile {
open the file;
determine its size;
allocate that much memory;
read the file into memory;
close the file;
}
第一眼看过去，这函数简单到不能再简单，但是它忽略了下列所有潜在的问题：
- 如果文件不能打开怎么办？
- 如果不能确定文件的大小怎么办？
- 如果内存不够分配怎么办？
- 如果文件读取失败怎么办？
- 如果文件不能关闭怎么办？
为了处理这些问题，readFile函数必须有更多的代码来处理错误检测、报告和处理。这个函数可能会变成这样：
errorCodeType readFile { initialize errorCode = 0; open the file; if (theFileIsOpen) { determine the length of the file; if (gotTheFileLength) { allocate that much memory; if (gotEnoughMemory) { read the file into memory; if (readFailed) { errorCode = -1; } } else { errorCode = -2; } } else { errorCode = -3; } close the file; if (theFileDidntClose && errorCode == 0) { errorCode = -4; } else { errorCode = errorCode and -4; } } else { errorCode = -5; } return errorCode; }
有那么多的错误检测、报告和返回语句，让原本简单的5行代码完全迷失在乱哄哄的代码里面了。更糟糕的是，代码的逻辑流程也随着丢失了，因此很难说这段代码是否做了正确的事：当函数分配内存的时候失败了，文件能否确保被关闭？当你三个月之后再修改这段代码时，你就更难确定改完后代码还到底能不能用了。很多程序员解决的办法就是简单地忽略它——当他们的程序崩溃了报告一下错误就行。
Exception可以让你能在一个地方写好代码主流程，在另外一个处理异常情况。如果readFile函数改用Exception来替换传统的错误管理技术，看起来就像下面的代码：
readFile { try { open the file; determine its size; allocate that much memory; read the file into memory; close the file; } catch (fileOpenFailed) { doSomething; } catch (sizeDeterminationFailed) { doSomething; } catch (memoryAllocationFailed) { doSomething; } catch (readFailed) { doSomething; } catch (fileCloseFailed) { doSomething; } }
要注意的是，使用Exception并不会让你在检测、报告和处理错误时更省力，但是可以让你把这些工作组织起来更高效。
优势2：在调用栈中向上传播错误
Exception的第二个优势就是，可以把错误报告给调用栈的上层方法。假如在主程序中，在一系列嵌套的调用方法中，readFile方法是第四个方法： method1调用method2，然后调用method3，最后调用readFile。
method1 {
call method2;
}
method2 {
call method3;
}
method3 {
call readFile;
}
假设method1是唯一关心在readFile内发生了什么错误的方法。传统的错误通知技术强制method1和method2传播readFile返回的错误代码，直到错误代码最后传到method1——而method1是唯一需要返回码的方法。
method1 { errorCodeType error; error = call method2; if (error) doErrorProcessing; else proceed;} errorCodeType method2 { errorCodeType error; error = call method3; if (error) return error; else proceed;} errorCodeType method3 { errorCodeType error; error = call readFile; if (error) return error; else proceed;}
回忆一下，Java运行时系统通过逆向搜索，查找对某个异常感兴趣的任何方法。一个方法可以躲避任何抛给它的异常，从而让一个方法可以把异常抛到更远的调用栈中捕获。因此，只有关心错误的方法，才必须要去检测错误。
method1 { try { call method2; } catch (exception e) { doErrorProcessing; } } method2 throws exception { call method3; } method3 throws exception { call readFile; }
然而，正如伪代码所示，中间人方法可以躲避掉后面必须要处理的异常。一个方法通过在throws从句中进行声明，可以抛掉任何检查异常。
优势3：归类和区分错误类型
因为程序抛出的所有异常都是对象，类是有层次结构的，所以对异常进行归类或分组是非常自然的结果。在Java平台中有一个例子，一组相关异常被定义在java.io包——IOException及其子类。IOException是最通用的，它代表了我们在执行I/O相关操作的时候发生的任何错误类型。它的继承者代表了更加细分的错误。例如，FileNotFoundException表示一个文件不能再磁盘中定位到。
一个方法可以写一个具体的处理器，能处理一个十分具体的异常。由于FileNotFoundException没有继承者，所以下面的这个异常处理器只能处理一种类型的异常：
catch (FileNotFoundException e) { ... }
一个方法也可以用更通用的处理器捕获处理具体的异常。例如，为了捕获所有的I/O异常，不管具体的类型是什么，只要给异常处理器指定一个IOException参数就行。
catch (IOException e) { ... }
这个处理器可以捕获所有的I/O异常，包括FileNotFoundException，EOFException等等。你可以通过查询传给异常处理器的参数，发现错误发生的细节。例如，用下面的代码打印堆栈跟踪信息：
catch (IOException e) { // Output goes to System.err. e.printStackTrace(); // Send trace to stdout. e.printStackTrace(System.out); }
你甚至可以构建一个可以处理所有异常的异常处理器：
// A (too) general exception handler catch (Exception e) { ... }
在Throwable类层级结构中，Exception类已经快接近顶点了。所以这个处理器将会捕获很多它不想捕获的异常。如果你想在整个程序中对所有异常都采取统一处理方式，你就可能会采取这种办法处理异常，例如，给用户打印错误信息并退出。
然而在大多数情况下，你希望异常处理器越具体越好。理由是在你决定最佳的恢复策略之前，你首先要知道错误的类型。事实上，如果不捕获具体的错误，这个处理器就必须要容纳任何可能性。太通用的异常处理器可能会让代码更容易出错，因为它们会捕获和处理程序员意料之外的异常，这样就超出处理器的能力范围了。
就像前面说过的，你可以创建一组异常，然后采用通用处理的风格。或者你可以使用具体的异常类型来区分不同的异常，然后用精确的风格处理异常。
转自:http://leaforbook.com/blog/jexception/translate/advantages.html
