Practicle Java笔记 实践16-27（异常处理部分）
实践16
异常之所以复杂，因为其类似于goto语句
如果同时存在catch块和finally块，则先进入catch再执行finally，如果没有catch块，则直接执行finally
实践17
产生异常的选择：1 捕捉并处理 2 捕捉并再次抛出 3 捕捉并抛出新异常 4 不捕捉
不要忽略异常 尽可能的就地处理 不要捕捉了异常但是不做任何事 至少打印留下log以便记录
实践18
当在处理异常期间 在catch或finally块中又抛出异常 则先前的异常会被屏蔽隐藏 这样就丢失了最初的错误信息
可以将期间所有的异常放入一个容器中
实践19
throw子句的缺点 在前期就设计好异常处理策略
处理异常有2种（1 自身处理 2 让调用者处理） 这会导致后期给一个小方法添加异常处理 如果该方法不具备能力自身解决 则需要让调用者处理 如果调用者依旧无法处理 则会继续向上 直至main 如果该小方法又多次被调用 会使程序的修改维护变得困难复杂
实践20
将函数可能抛出的异常统统列出是一个良好的变成习惯，不要因为这些异常都派生自另一个异常就不单独列出
如果复写了某个抛出异常的函数 那么：
1 不抛出异常 2 抛出相同的异常 3 抛出原异常的派生异常
实践21
在finally中对非内存类的资源进行释放（比如I/O流等） finally块无论如何都会被执行 不执行finally是不可能推出try区段的
实践22
不要在try语段中发出对return,break或是continue语句的调用
万一无法避免，一定要确保finally的出现不会改变函数的返回值
try{
return 2;
}finally{
return 4;
}
以上代码会返回4
实践23
将try-catch置于循环之外 对于没有JIT能力的JVM 会有性能上的提升
不启用JIT的情况下执行Test.class：
Java - Djava.compiler=NONE Test
实践24
不要将异常用于流程控制 异常只用于异常情况
实践25
不要每逢出错就使用异常，“可以预期的行为”应当使用传统的方式处理（返回代码，判断等） 只有不可预知的才用异常（文件损坏等）
实践26
如果构造函数可能失败 考虑在构造函数中抛出异常（构造函数没有返回值） 这样的方式更强固和高效（相对于制造一个成功构建的标志位，或检测某状态值判断成功与否等）
实践27
确保异常发生后，代码仍能按预想正确运行，在抛出异常前将所有的对象恢复为有效的状态
这类似于事务，必须有提交+回滚的机制