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

确保异常发生后，代码仍能按预想正确运行，在抛出异常前将所有的对象恢复为有效的状态

这类似于事务，必须有提交+回滚的机制