本文共 1053 字，大约阅读时间需要 3 分钟。
最近在用spring boot 做微服务，所以对于异常信息的 【友好展示】有要求，我设计了两点：
一、 在业务逻辑代码中，异常的抛出 我做了限定，一般只会是三种：
| 1 2 3 | 1 . OmcException //自己写的异常包装类 ，主要用来处理业务异常 2 . IllegalArgumentException //参数异常类，其实这个可以不要，只是在我的系统中，我想把参数异常和业务异常做区分 3 . 其他的异常，都按Exception抛 //因为它的抽象层次最高，所以在系统中按优先级最低进行处理，除非必要（如容器级错误）否则尽量避免 |
OmcException的构造是这样的：
这里留个钩子：
为什么要在抛异常时，带上 日志的信息 + 输入参数的信息？
—— 因为，我希望在业务逻辑代码中，对于这些异常的处理，最好就是一行代码，类似于：打印error日志 + 向用户返回友好的错误信息。我想做一个公共的处理模块。让业务逻辑代码尽可能的清爽一些。
对异常的进行try-catch包装的过程是：
对异常的抛出做限定，给个总结就是：尽量包装成我们自己封装的异常包装类。
为什么呢？ 这是在设计上做限定，那么后进的程序员，如果不按照这个规范走，功能是做不出来的。这个也是架构设计的意义，不要随便动个嘴就好，还要把栅栏建好。
二、 在公共的业务逻辑处理代码中，异常的接收（或者说异常的路由） 我做了限定，一般是：
1. 先匹配业务异常。业务异常一般向用户提示什么呢？ 错误编码 + 错误提示信息。
2. 其次，匹配参数异常，这些参数异常可能是我们自己做参数校验抛出来的，也有可能是spring mvc 抛出来的，所以还没有到我们的业务逻辑代码中。
参数异常一般提示什么呢？ 错误提示信息（包含哪个字段出现了错误）
3. 根异常Exception，这里捕获的异常，可能是我们不愿意处理的 数据库异常，也有可能是容器报的异常（当然，这些异常我们并不能捕获所有的。）这里要做打error日志的处理。
一个设计良好的系统，最好是不要走进这个分支，毕竟分析error日志不是一件多么光荣的事儿。
spring boot中，公共异常处理模块代码结构是：
然后是，打印error日志 + 向用户返回友好的错误信息
本文转自二郎三郎博客园博客，原文链接：http://www.cnblogs.com/haore147/p/6088829.html，如需转载请自行联系原作者