个人经验总结
一定要想好在发生异常时，最外层应该给用户或使用者怎样的信息，内层应该有怎样的正确逻辑处理，还要保留适当的日志和现场信息等。
为什么要做异常处理（在可预期的无法提前避免的异常发生时）
保证程序不崩溃
保证异常信息不会一直上抛到最上层，暴露给用户（要做适当的异常处理，或者转成对用户友好的信息）
有日志或异常堆栈等现场信息可以存下来
一些底层的异常（如依赖的library抛出的异常），对于调用者系统来说，不一定就是异常，可以转换成对用户友好的信息。
比如使用依赖的library调用http接口，如果接口返回404，library可能会当成异常抛出，而调用者不一定把它当成异常。
分层异常处理规约
对于web的多层架构，应该在哪一层做异常处理？是否继续上抛？
关键要看发生异常以后，业务上应该要怎么处理。
（看具体场景，常用）如果发生异常后，上层会有统一的异常处理（也可能是通过切面的方式来做统一的异常处理），那么本层就可以不做异常处理，或者catch住后再重新抛出一个该层的自定义Exception，方便上层做专门的catch和处理，比如DAOException。然后上层依次处理各种类型的异常。
（看具体场景，偶尔用）如果发生异常后要返回给上层false，那么当然就要catch以后return一个false，让上层知道操作失败了。但是这样有弊端，一个是如果DAO方法的返回类型不是bool类型的话，通过其他方式传出比较麻烦；一个是这样的话上层service层虽然不需要做异常处理了（但有可能因为其他原因，这个异常处理的代码还是免不了的），但是每个DAO操作都要做返回值判断。
（不太常用）如果无论怎样都上层都要继续执行，下层异常也业务上没关系，那么就可以在下层catch住记个日志就行了，不需要往上抛了。
DAO层。
产生的异常类型有很多，无法用细粒度的异常进行catch，使用catch(Exception e)方式，并throw new DAOException(e)，方便上层对该DAOException类型做专门的catch和处理，不需要打印日志，因为日志在Manager/Service层一定需要捕获并打印到日志文件中去，如果同台服务器再打日志，浪费性能和存储。
当然还有一种方式，是catch(Exception e)后返回false，让上层service层知道操作失败了。但是这样有弊端，一个是如果DAO方法的返回类型不是bool类型的话，通过其他方式传出比较麻烦；一个是这样的话上层service层虽然不需要做异常处理了（但有可能因为其他原因，这个异常处理的代码还是免不了的），但是每个DAO操作都要做返回值判断。
Service层。
在Service层出现异常时，必须记录出错日志到磁盘，尽可能带上参数信息，相当于保护案发现场。如果Manager层与Service同机部署，日志方式与DAO层处理一致，如果是单独部署，则采用与Service一致的处理方式。
注意结合其他原则，比如通过预检查方式规避的RuntimeException异常、要分清稳定代码和非稳定代码等。
Web层或开放接口层。
绝不应该继续往上抛异常，因为已经处于顶层，如果意识到这个异常将导致页面无法正常渲染，那么就应该直接跳转到友好错误页面，加上用户容易理解的错误提示信息。
要将异常处理成错误码和错误信息方式返回。
可以有通用的异常处理filter，转换各种异常到合适的错误信息
前后台交互中。
可以考虑后台返回信息中包含错误码、错误信息，但不要包含错误堆栈（因为前端在浏览器中会暴露给客户），然后前台可以直接显示错误信息，也可以自己再根据错误码展示相应信息，尤其在做了国际化时，得看国际化是前端还是后端做的，如果是前端做的并且错误信息要国际化，那只能前端再转一次找到对应的错误信息了。
自定义异常类型
可以使用更有用的异常信息。
方便上层进行异常处理时做分类、针对性的处理。
一般最后再用或者不要用通用的Exception类型，这样可以在处理不同的异常类型时做不同的处理，或者记录不同的日志，或者返回不同的信息。
不一定在catch中重新throw时使用，也可以在适当的业务场景下直接throw。
catch的异常类型
在全局异常处理类中，或者上层的异常处理逻辑中，先处理自定义异常，再处理特殊需要的异常，最后所有的异常全部归在Exception中，统一告诉前端用户操作失败请联系管理员就好啦。
不过很多时候不会去catch通用的Exception，都是catch自定义异常、依赖包指明会抛出的具体异常类型等。
像NullPointerException，IndexOutOfBoundsException等可以通过预检查方式规避的RuntimeException异常，就不要再做异常处理了，提前做一下判断比较好。
不要用异常处理做流程控制、条件控制。
捕获异常是为了处理它，不要捕获了却什么都不处理而抛弃之。应该采取怎样的处理方式？记一下日志完事？记完再抛给上一层？
不要不分青红皂白就把所有的代码catch住，然后匹配一个通用的Exception，再处理下就完事。要分清稳定代码和非稳定代码，只处理非稳定代码的异常。
有try块放到了事务代码中（比如Spring的@Transaction），catch异常后，如果需要回滚事务，一定要注意手动回滚事务
finally块必须对资源对象、流对象进行关闭，有异常也要做try-catch。
不要在finally块中使用return
设计思路
强制
Java 类库中定义的可以通过预检查方式规避的RuntimeException异常不应该通过catch 的方式来处理 ，比如：NullPointerException，IndexOutOfBoundsException等等。
无法通过预检查的异常除外，比如，在解析字符串形式的数字时，可能存在数字格式错误，不得不通过catch NumberFormatException来实现。
正例：if (obj != null)
反例：try { obj.method(); } catch (NullPointerException e)
经验：也就是说，这些能够提前通过代码判断出来的问题，就提前判断算了，不要再让异常抛出来增加复杂度了。只有不容易判断，运行时才出现的问题，才catch，比如接口调用失败、HttpClientErrorException、InterruptedException、JwtException、NoSuchAlgorithmException、InvalidKeySpecException、IOException、业务自定义异常等。
异常不要用来做流程控制，条件控制 。
异常设计的初衷是解决程序运行中的各种意外情况，且异常的处理效率比条件判断方式要低很多。
经验：异常和流程控制、条件控制根本就是两回事，目的不同。
捕获异常是为了处理它，不要捕获了却什么都不处理而抛弃之 ，如果不想处理它，请将该异常抛给它的调用者。
经验：也就是说不要平白无故的吃掉异常，至少要做个日志记录，或者直接抛给上层，当然这要看业务上怎么考虑的，怎么做比较合适，和上层是怎么配合的。
最外层的业务使用者，必须处理异常，将其转化为用户可以理解的内容 。
经验：比如在controller层，就可以用一个@ControllerAdvice来定义一个全局的异常处理类，能指定哪些异常转换成哪种响应码，来返回有效的异常信息和响应码。
捕获异常与抛异常，必须是完全匹配，或者捕获异常是抛异常的父类 。
如果预期对方抛的是绣球，实际接到的是铅球，就会产生意外情况。
catch时请分清稳定代码和非稳定代码 ，稳定代码指的是无论如何不会出错的代码。对于非稳定代码的catch尽可能进行区分异常类型，再做对应的异常处理。
对大段代码进行try-catch，使程序无法根据不同的异常做出正确的应激反应，也不利于定位问题，这是一种不负责任的表现。
经验：这是因为有的代码出现了异常，这是正常的要交给上层处理的，不能一股脑全括起来catch住，那这种正常的异常就抛不出来。
正例：用户注册的场景中，如果用户输入非法字符，或用户名称已存在，或用户输入密码过于简单，在程序上作出分门别类的判断，并提示给用户。
经验：也就是说要自己判断哪些代码会抛异常，哪些不会抛，不要用一个大try把所有代码都catch住，这样不利于出异常时定位问题，只是为了图省事。
经验：如前面提到的做法，最外层的业务使用者，必须处理异常，这时倒是可以考虑把最外层全做异常处理，但也不一定要用try全包住，可以用前面说的@ControllerAdvice来进行切面处理各种异常，当然这种做法事实上好像和全用try包住也差不多。。。
参考
对于公司外的http/api开放接口必须使用“错误码”；而应用内部推荐异常抛出；跨应用间RPC调用优先考虑使用Result方式，封装isSuccess()方法、“错误码”、“错误简短信息” 。
关于RPC方法返回方式使用Result方式的理由：
1）使用抛异常返回方式，调用方如果没有捕获到就会产生运行时错误。
2）如果不加栈信息，只是new自定义异常，加入自己的理解的error message，对于调用端解决问题的帮助不会太多。如果加了栈信息，在频繁调用出错的情况下，数据序列化和传输的性能损耗也是问题。
避免出现重复的代码（Don't Repeat Yourself），即DRY原则 。
随意复制和粘贴代码，必然会导致代码的重复，在以后需要修改时，需要修改所有的副本，容易遗漏。必要时抽取共性方法，或者抽象公共类，甚至是组件化。
正例：一个类中有多个public方法，都需要进行数行相同的参数校验操作，这个时候请抽取：private boolean checkParam(DTO dto)
具体情况
强制
有try块放到了事务代码中（比如Spring的@Transaction），catch异常后，如果需要回滚事务，一定要注意手动回滚事务 。finally块必须对资源对象、流对象进行关闭，有异常也要做try-catch 。
如果JDK7及以上，可以使用try-with-resources方式。
不要在finally块中使用return 。
try块中的return语句执行成功后，并不马上返回，而是继续执行finally块中的语句，如果此处存在return语句，则在此直接返回，无情丢弃掉try块中的返回点。
反例：finally中在return前又修改了返回值，那么调用方收到的就是修改后的返回值了。
在调用RPC、二方包、或动态生成类的相关方法时，捕捉异常必须使用Throwable类来进行拦截 。
通过反射机制来调用方法，如果找不到方法，抛出NoSuchMethodException。什么情况会抛出NoSuchMethodError呢？二方包在类冲突时，仲裁机制可能导致引入非预期的版本使类的方法签名不匹配，或者在字节码修改框架（比如：ASM）动态创建或修改类时，修改了相应的方法签名。这些情况，即使代码编译期是正确的，但在代码运行期时，会抛出NoSuchMethodError。
推荐
方法的返回值可以为null，不强制返回空集合，或者空对象等，必须添加注释充分说明什么情况下会返回null值。
本手册明确防止NPE是调用者的责任 。即使被调用方法返回空集合或者空对象，对调用者来说，也并非高枕无忧，必须考虑到远程调用失败、序列化失败、运行时异常等场景返回null的情况。
经验：不要只要求下层被调用者返回的结果怎样怎样，自己一定还是要做NPE（NullPointerException）等检查。
防止NPE，是程序员的基本修养 ，注意NPE产生的场景：
1） 返回类型为基本数据类型，return包装数据类型的对象时，自动拆箱有可能产生NPE。
反例：public int f() { return Integer对象}， 如果为null，自动解箱抛NPE。
2） 数据库的查询结果可能为null。
3） 集合里的元素即使isNotEmpty，取出的数据元素也可能为null。
4） 远程调用返回对象时，一律要求进行空指针判断，防止NPE。
5） 对于Session中获取的数据，建议进行NPE检查，避免空指针。
6） 级联调用obj.getA().getB().getC()；一连串调用，易产生NPE。
正例：使用JDK8的Optional类来防止NPE问题 。
定义时区分unchecked / checked 异常，避免直接抛出new RuntimeException()，更不允许抛出Exception或者Throwable，应使用有业务含义的自定义异常 。推荐业界已定义过的自定义异常，如：DAOException / ServiceException等。
