|Practical Java| Chapter 3 Exception Handling
欲撰写能够正确处理错误状态的强固软件, 必须深刻理解其中设计的机制.
16> 认识 [异常控制流] (Exception control flow) 机制
EH 采用了类似的技术, 一旦异常诞生,控制流立刻转移到下面3者之一:
A> catch block (捕获区段)
B> finally block (终结区段)
C> calling Method (调用端)
17> Never ignore an Exception ( 绝对不可忽视异常)
如果异常产生却未被捕获,发生异常的那个 Thread 将因而中断.
当程序产生异常:
A> 捕获并处理她, 防止进一步传播(propagate);
B> 捕获并再次抛出, 此时她会传播给调用端;
C> 捕获她,然后抛出一个新异常给调用端;
D> 不捕获这个异常, 听任传播给调用端;
以一种草率的方式对异常听任不管, 即代码捕获异常,却对她不进行处理 -----
吞噬异常. 这样会比忽略返回码引起更多的麻烦, 是很不明智的.
在没有更好的处理方法前可以使用 LogException() [异常日志记录]和PrintStackTrace
[异常信息]来暂时处理, 当然这不是个好办法.
18> Never hide an Exception (不要遮掩异常)
try / catch / finally 区段可以彼此任意嵌套(nested), 尽管从她们之中抛出了多个
异常, 也只会有一个异常可被传到外界. --- 即最后被抛出的那个异常. 其他
的异常都被覆盖而遗失.
解决异常的遗失, 以明确程序问题的初始原因, 就绝不能覆盖任何异常. 可以用
Vector 记录每一次异常的发生.
19> 明察Throws 子句的缺点
throws 子句是一种语言机制, 用以列出 [可从某个函数传至外界] 的所有可能异常.
编译器强迫你必须在函数中捕捉这些被列出的异常, 否则就得在该函数的
rhrow子句中声明她们. throws子句用来向函数调用者发出预警,告知将会产
生那些异常.
在程序中, 请一开始就设计好你的错误处理策略,而不是在开发周期最后才添加异
常的处理.
21> 使用 finally 避免资源泄漏 (resource leaks)
在维护对象内部状态和清理 non-memory 资源方面,finally尤其试用.