标签：Exception 处理 抛出 捕获 打印 try 异常
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的，具体的自己看吧。我个人就认为图二代码更方便简洁，看着舒服，当然这是仁者见仁智者见智，按自己个人的喜好吧。
图一：
图二：
标签：Exception,处理,抛出,捕获,打印,try,异常 来源： https://www.cnblogs.com/yuanzipeng/p/12743535.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。