最近在用spring boot 做微服务，所以对于异常信息的 【友好展示】有要求，我设计了两点：

一、 在业务逻辑代码中，异常的抛出 我做了限定，一般只会是三种：　　　　　　　　　　　

   　OmcException的构造是这样的：

这里留个钩子：

为什么要在抛异常时，带上 日志的信息 + 输入参数的信息？

　　　　　　　—— 因为，我希望在业务逻辑代码中，对于这些异常的处理，***就是一行代码，类似于：打印error日志 + 向用户返回友好的错误信息。我想做一个公共的处理模块。让业务逻辑代码尽可能的清爽一些。

对异常的进行try-catch包装的过程是：

对异常的抛出做限定，给个总结就是：尽量包装成我们自己封装的异常包装类。

    为什么呢？ 这是在设计上做限定，那么后进的程序员，如果不按照这个规范走，功能是做不出来的。这个也是架构设计的意义，不要随便动个嘴就好，还要把栅栏建好。

二、 在公共的业务逻辑处理代码中，异常的接收（或者说异常的路由） 我做了限定，一般是：

1. 先匹配业务异常。业务异常一般向用户提示什么呢？ 错误编码 + 错误提示信息。

2. 其次，匹配参数异常，这些参数异常可能是我们自己做参数校验抛出来的，也有可能是spring mvc 抛出来的，所以还没有到我们的业务逻辑代码中。

　　参数异常一般提示什么呢？ 错误提示信息（包含哪个字段出现了错误）

3. 根异常Exception，这里捕获的异常，可能是我们不愿意处理的 数据库异常，也有可能是容器报的异常（当然，这些异常我们并不能捕获所有的。）这里要做打error日志的处理。

　　一个设计良好的系统，***是不要走进这个分支，毕竟分析error日志不是一件多么光荣的事儿。

spring boot中，公共异常处理模块代码结构是：

然后是，打印error日志 + 向用户返回友好的错误信息

 本文转自二郎三郎博客园博客，原文链接：http://www.cnblogs.com/haore147/p/6088829.html，如需转载请自行联系原作者