浅谈日志中的返回格式封装格式处理，异常处理

选型问题不谈，主要考虑info 级别的数据：

一般信息：

一般说来，我们都会上项目上封装一个返回异常类，用来包装信息。
通常我们来说就是返回码和返回信息，这种最常见了。
为了更好的检查问题，我们设计如下：
000000-业务成功
000001-业务失败等

对于Msg信息呢：
我们可以定义信息格式：或信息提示。
这样在就可以不同的流程信息中输出对应的封装信息了。
信息最好有规则话，如XX，原因，便于上线grep 搜索

一般这个就可以了。

异常处理：

我们知道异常的层次：

我们可以定义自己的异常类，一般不太常用，但是可以这么做。
更多的是借助框架提供的异常：
Spring MVC 有以下 3 种处理异常的方式：

使用 Spring MVC 提供的简单异常处理器 SimpleMappingExceptionResolver。
实现 Spring 的异常处理接口 HandlerExceptionResolver，自定义自己的异常处理器。
使用 @ExceptionHandler 注解实现异常处理

直接从框架上继承异常并处理。即可。

处理方式：

直接抛出，交由系统处理。
自己捕捉异常并处理。

1. 异常处理基础
   1.1 System.out.println是高代价的。调用System.out.println会降低系统吞吐量。

   1.2 在生产环境中别用异常的printStackTrace()方法。printStackTrace默认会把调用的堆栈打印到控制台上，在生产环境中访问控制台是不现实的。

2. 异常处理基本原则
   2.1 如果你不能处理异常，不要捕获该异常。

   2.2 如果要捕获，应在离异常源近的地方捕获它。

   2.3 不要吞没你捕获的异常。
   *（就是捕获的异常，但是什么也不做）

   2.4 除非你要重新抛出异常，否则把它log起来。

   2.5 当一个异常被重新包装，然后重新抛出的时候，不要打印statck trace。

   2.6 用自定义的异常类，不要每次需要抛出异常的时候都抛出java.lang.Exception。方法的调用者可以通过throws知道有哪些异常需要处理–所以它是自我描述的。

   2.7 如果你编写业务逻辑，对于终端用户无法修复的错误，系统应该抛出非检查的异常（unchecked exception）；如果你编写一个第三方的包给其他的开发人员用，对于不可修复的错误要用需要检查的异常（checked exception）。

   2.8 绝对不要因为写throws语句会让你用起来不舒服，而不声明需要检查的异常。

   2.9 应用级别的错误或不可修复的系统异常用非检查的异常（unchecked exception）抛出。
   *（注意是错误，意味着不可修复，比如配置文件错误）

   2.10 根据异常的粒度组织你的方法

简而言之：log 打印异常，，自定义异常，注意受检异常。
一般打印即可，系统已经默认了异常。

推荐阅读：
https://www.cnblogs.com/langtianya/p/6931190.html