1、Java的异常处理机制带来的性能损失
try-catch 代码段会产生额外的性能开销,会影响JVM对代码进行优化,所以建议仅仅捕获必要的代码段,尽量不要一个大的try包住整段代码;利用异常控制代码流程,也远比条件语句(if/else、switch)要低效,Java每实例化一个Exception,都会对当时的栈进行快照。如果发生的非常频繁了,这个新能德开销也是不可忽略的。
2、自定义异常需要考虑两点
(1)是否需要定义成可检查异常,因为这种类型设计的初衷就是为了从异常情况中恢复。
(2)在保证诊断信息足够的同时,还要考虑避免包含敏感信息,这样可能导致潜在的安全问题。比如用户的数据一般不可以输出到日志中。
3、不要生吞异常,也不要既打印异常又抛出异常
不要在捕获异常后直接掩盖问题(生吞异常),如果我们不把异常抛出来,或者没有输出到日志,程序可能在后续代码以不可控的方法结束。这样不好判断究竟是哪里抛出异常。碰到这种我们不知道怎么处理的异常,我们可以选择保留原有异常的信息,直接再抛出。也不要既打印异常又抛出异常,这样会把同样的一个异常问题重复打印,建议最好就直接用error日志级别把异常信息打印出来。
反例:
try{} catch(Exception e){//异常捕获不做任何处理}
try{} catch(Exception e){
//不要既打印异常又抛出异常
logger.error("异常说明"+e);
throw e;
}
正例:
try{} catch(Exception e){
//打印日志输出控制台以便开发人员查找问题
logger.error("异常说明"+e);
}
4、不要在finally里抛出异常
有大佬说在finally里抛出异常,将会覆盖原始的异常,我个人认为不是这个原因。看下面的demo,很明显在finally里抛出异常代码是标红错误的,而且运行时也显示:必须对其进行捕获或声明以便抛出,但是对其进行捕获或声明就正确的吗?很明显也不行。
5、对于使用一些重量级资源的操作,发生异常时,要记得清理
如网络连接,数据库操作等,要记得在finally块里close、clean up。
6、不要使用异常来控制程序逻辑流程
有些人经常这么做,这样使得代码变得丑陋,使得正常业务逻辑和异常处理混淆不清,而且也可能会出现性能问题,因为异常是一个比较重的操作。
7、大多数人说尽量不要捕获类似Exception这样的通用异常,而是应该捕获特定的异常
大多数人说尽量不要捕获类似Exception这样的通用异常,而是应该捕获特定的异常,因为这样就违反了可检查异常设计的初衷,调用的Exception都不知道是什么,也不知道该如何处理,比如图一不仅捕获了自定义的ApplicationException异常,还捕获了系统异常SystemException和通用异常Exception。说实话我是不赞同图一这样的做法的,我是比较喜欢图二的做法,至于什么可检查异常设计的初衷,你怎么知道这就是设计者的初衷呢?而且就算是设计者的初衷就不能更改了吗?而且看源码Exception是继承Throwable的,然后所有可检查异常又是继承自Exception的,具体的自己看吧。我个人就认为图二代码更方便简洁,看着舒服,当然这是仁者见仁智者见智,按自己个人的喜好吧。
图一:
图二: