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的，具体的自己看吧。我个人就认为图二代码更方便简洁，看着舒服，当然这是仁者见仁智者见智，按自己个人的喜好吧。
图一：
图二：
