`

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

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

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

 

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics