优雅处理你的Java异常

优雅处理你的Java异常_第1张图片

作者:叶知泉

来源:https://my.oschina.net/c5ms/blog/1827907


本文介绍


本文仅按照业务系统开发角度描述异常的一些处理看法,不涉及java的异常基础知识,可以自行查阅 《Java核心技术 卷I》 和 《java编程思想》 可以得到更多的基础信息。


写在前面的话


笔者文笔功力尚浅,言语多有不妥,请慷慨指正,必定感激不尽. 本文提出了几个概念: 处理反馈;业务异常;代码错误。


请认真思考一下各中区别。


在开发业务系统中,我们目前绝大多数采用MVC模式,但是往往有人把service跟controller紧紧的耦合在一起,甚至直接使用Threadlocal来隐式传值,并且复杂的逻辑几乎只能使用service中存储的全局对象来传递处理结果,包括异常。


这样一来首先有违MVC模式,二来逻辑十分不清晰,难以维护。本文结合工作经验,给出一些异常使用建议,使用spring来实战异常为我们带来的好处。


常常,我们读罢了各种java的书,异常的各种机制,特性都很清楚,但是始终还是不知道如何使用,甚至背下了概念,却不知道如何致用。


我们开发的业务系统,或者是产品,常常面临着这样的问题:

  • 系统运行出错,但是完全不知道错误发生的位置

  • 我们找到了错误的位置,但是完全不知道是因为什么

  • 系统明明出了错误,但是就是看不到错误堆栈信息


什么情况需要自定义异常


经常看到一些项目,在全局定义一个 AppException,然后所有地方都只抛出这个异常,并且把捕获的异常case到这个AppException中.会有如下问题:

  • 浪费log日志存储空间,并且栈顶并不是最接近发生异常的代码位置

  • 只有一种异常类,无法精准区分开异常类型

  • 异常类后期难以修改以增加其携带的信息


什么情况需要手动处理异常


我不会把书上的东西直接复制下来,这里说一下容易记住的,并且适合业务开发的。

  • 你有能力处理异常,并且你知道如何处理

  • 你有责任处理异常


自定义业务异常


考虑如下场景: 系统提供一个API,用于修改用户信息,服务器端采用json数据交互.首先我们定义ServiceException,用来表示业务逻辑受理失败,它仅表示我们处理业务的时候发现无法继续执行下去。


 
   
  1. /**

  2. * 业务受理失败异常

  3. */

  4. public class ServiceException extends RuntimeException {

  5.    //接收reason参数用来描述业务失败原因.

  6.  public ServiceException(String reason) {  super(reason); }

  7. }


接下来看下Controller层

 
   
  1. // UserController.java

  2. /**

  3.   * 修改用户信息

  4.   * @param userID 用户ID

  5.   * @param user 修改用户信息表单数据

  6.   */

  7.  @PutMapping("{userID}")

  8.  public JSONResult updateUser(@PathVariable("userID") Integer userID, @RequestBody UpdateUserForm userForm) {

  9.    User user = new User(); //准备业务逻辑层使用的领域模型

  10.    BeanUtils.copyProperties(userForm, user); //拷贝要修改的值

  11.    user.setUserId(userID); //设置主键到用户数据中

  12.    userService.updateUser(user); //调用更新业务逻辑

  13.    JSONResult json = new JSONResult(); //准备要响应的数据

  14.    json.put("user", user); //把修改后的用户数据还给页面

  15.    return json; // --  

  16.  }


关于上述Controller写法乍一看会有一些冗余,如果无法理解,请仔细研读MVC设计模式. 先不管service,我们来考虑下. 一个业务系统不可能不对用户提交的数据进行验证,验证包括两方面 : 有效性和合法性。

  • 有效性: 比如用户所在岗位,是否属于数据库有记录的岗位ID,如果不存在,无效。

  • 合法性: 比如用户名只允许输入最多12个字符,用户提交了20个字符,不合法。


有效性检查,可以交给java的校验框架执行,比如JSR303. 假设用户提交的数据经过验证都合法,还是有一些情况是不能调用修改逻辑的。

  1. 要修改的用户ID不存在

  2. 用户被锁定,不允许修改

  3. 乐观锁机制发现用户已经被被人修改过

  4. 由于某种原因,我们的程序无法保存到数据库

  5. 一些程序员错误的开发了代码,导致保存过程中出现异常,比如NPE


对于前3种,我们认为是有效性检查失败,第4种属与我们无法处理的异常,第5种就是程序员bug。


现在的问题是,前三种情况我们如何通知用户呢?

  1. 在ccontroller 调用userService的checkUserExist()方法

  2. 在controller直接书写业务逻辑

  3. 在service响应一个状态码机制,比如1 2 3表示错误信息,0 表示没有任何错误


显然前2种方法都不可取 ,因为MVC不设计模式告诉我们,controller是用来接收页面参数,并且调用逻辑处理,最后组织页面响应的地方。我们不可以在controller进行逻辑处理,controller只应该负责用户API入口和响应的处理(如若不然,思考一下如果有一天service的代码打包成jar放到另一个平台,没有controller了,该怎么办?)


状态码机制是个不错的选择,可是如此一来,用户保存逻辑变了,比如增加一个情况,不允许修改已经离职的用户,那么我们还需要修改controller的代码,代码量增加,维护成本增高,并且还耦合了service,不符合MVC设计模式。


那么怎么办呢?

现在我们来看下service代码如何编写

 
   
  1.  /**

  2.   * 修改用户信息

  3.   * @param user 要修改的用户数据

  4.   */

  5.  public void updateUser(User user) {

  6.    User userOrig = userDao.getUserById(user.getUserID());

  7.    if (null == userOrig) {

  8.      throw new ServiceException("用户不存在");

  9.    }

  10.    if (userOrig.isLocked()) {

  11.      throw new ServiceException("用户被锁定,不允许修改");

  12.    }

  13.    if (!user.getVersion().equals(userOrig.getVersion())) {

  14.      throw new ServiceException("用户已经被别人修改过,请刷新重试");

  15.    }

  16.    // TODO 保存用户数据  ...

  17.  }


这样一来只要我们检查到不允许保存的项目,我们就可以直接throw 一个新的异常,异常机制会帮助我们中断代码执行。

接下来有2种选择:

  • 在controller 使用try-catch进行处理

  • 直接把异常抛给上层框架统一处理


第1种方式是不可取的 ,注意我们抛出的ServiceException,它仅仅逻辑处理异常,并且我们的方法前面没有声明throws ServiceException,这表示他是一个非受查异常.controller也没有关心会发生什么异常。


为什么不定义成受查异常呢? 

如果是一个受查异常,那么意味着controller必须要处理你的异常.并且如果有一天你的业务逻辑变了,可能多一种检查项,就需要增加一个异常,反之需要删除一个异常,那么你的方法签名也需要改变,controller也随之要改变,这又变成了紧耦合,这和用状态码123表示处理结果没有什么不同。


我们可以为每一种检查项定义一个异常吗? 

可以,但是那样显得太多余了.因为业务逻辑处理失败的时候,根据我们需求,我们只需要通知用户失败的原因(通常应该是一段字符串),以及服务器受理失败的一个状态码(有时可能不需要状态码,这要看你的设计了),这样这需要一个包含原因属性的异常即可满足我们需求。


最后我们决定这个异常继承自RuntimeException,并且包含一个接受一个错误原因的构造器,这样controller层也不需要知道异常,只要全局捕获到ServiceException做统一的处理即可,这无论是在struct1,2时代,还是springMVC中,甚至servlet年代,都是极为容易的!


异常不提供无参构造器 ,因为绝对不允许你抛出一个逻辑处理异常,但是不指明原因,想想看,你是必须要告诉用户为什么受理失败的!


如此一来,我们只需要全局统一处理下 ServiceException 就可以了,很好,spring为我们提供了ControllerAdvice机制,有关ControllerAdvice,可以查阅springMVC使用文档,下面是一个简单的示例:


 
   
  1. @ControllerAdvice(basePackages = { "com.xxx.xxx.bussiness.xxx" })

  2. public class ModuleControllerAdvice {

  3.  private static final Logger LOGGER = LoggerFactory.getLogger(ModuleControllerAdvice.class);

  4.  private static final Logger SERVICE_LOGGER = LoggerFactory.getLogger(ServiceException.class);

  5.  /**

  6.   * 业务受理失败

  7.   */

  8.  @ResponseBody

  9.  @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)

  10.  @ExceptionHandler(ServiceException.class)

  11.  private JSONResult handleServiceException(ServiceException exception) {

  12.    String message = "业务受理失败,原因:" + exception.getLocalizedMessage();

  13.    SERVICE_LOGGER.info(message);

  14.    JSONResult json = new JSONResult();

  15.    json.serCode(500001); // 500000表示系统异常,500001表示业务逻辑异常

  16.    json.setMessage(message);

  17.    return json;

  18.  }

  19. }


在这个时候,我们就可以很轻松的处理各种情况了。


注意一点,在这个类中,我们定义了2个log对象,分别指向 ServiceException.class 和 ModuleControllerAdvice.class . 并且处理 ServiceException的时候使用了info级别的日志输出,这是很有用的。

  • 首先,ServiceException一定要和其他的代码错误分离,不应该混为一谈

  • 其次,ServiceException并不一定要记录日志,我们应该提供独立的log对象,方便开关


接下来你可以在修改用户的时候想客户端响应这样的JSON


 
   
  1. {

  2.    code: 200001,

  3.    message: "业务受理失败,原因:用户名称不存在!"

  4. }


如此一来没有任何地方需要关心异常,或者业务逻辑校验失败的情况.用户也可以得到很友好的错误提示。


如何对异常进行分类


如果你只需要一句概括,那么直接定义一个简单的异常,用于中断处理,并且与用户保持友好交互即可。


如果不可能一句话描述清楚,并且包含附加信息,比如需要在日志或者数据库记录消息ID,此时可能专门针对这种重要/复杂业务创建独立异常。


上述两种情况因为web系统,是用户发起请求之后需要等待程序给予响应结果的。


如果是后台作业,或者复杂业务需要追溯性.这种通常用流程判断语句控制,要用异常处理.我们认为这些流程判断一定在一个原子性处理中.并且检查到(不是遇到)的问题(不是异常)需要记录到用户可友好查看的日志.这种情况属于处理反馈,并不叫异常。


综上,笔者通常分为如下几类:

  1. 逻辑异常,这类异常用于描述业务无法按照预期的情况处理下去,属于用户制造的意外

  2. 代码错误,这类异常用于描述开发的代码错误,例如NPE,ILLARG,都属于程序员制造的BUG

  3. 专有异常,多用于特定业务场景,用于描述指定作业出现意外情况无法预先处理


各类异常必须要有单独的日志记录,或者分级,分类可管理.有的时候仅仅想给三方运维看到逻辑异常。


写在后面的注意

异常设计的初衷是解决程序运行中的各种意外情况,且异常的处理效率比条件判断方式要低很多。


上面这句话出自,但是我们思考如下几点:

业务逻辑检查,也是意外情况


UnknownHostException,表示找不到这样的主机,这个异常和NoUserException有什么区别么?换言之,没有这样的主机是异常,没有这样的用户不是异常了么? 所以一定要弄明白什么是用异常来控制逻辑,什么是定义程序异常。


异常处理效率很低


书中所示的例子,是在循环中大量使用try-catch进行检查,但是业务系统,用户发起请求的次数与该场景天壤地别.淘宝的11`11是个很好的反例.但是请你的系统上到这个级别再考虑这种问题。

  1. 系统有千万并发,不可能还去考虑这些中规中矩的按部就班的方式,别忘了MVC本来就浪费很多资源,代码量增加很多

  2. 业务系统也存在很多巨量任务处理的情况.但是那些任务都是原子性的,现在MVC中的controller和service可不是原子性的,不然为什么要区分这么多层呢

  3. 如果那么在乎效率,考虑下重写Throwable的fillStackTrace方法.你要知道异常的开销大到底大在什么地方,fillStackTrace是一个native方法,会填充异常类内部的运行轨迹

不要用异常进行业务逻辑处理

我们先来看一个例子:

 
   
  1.    //这是一个非常典型的反例,也是一个误区.

  2.  /**

  3.   * 处理业务消息

  4.   * @param message 要处理的消息

  5.   */

  6.  public void processMessage(Message<String> message) {

  7.    try{

  8.        // 处理消息验证

  9.        // 处理消息解析

  10.        // 处理消息入库

  11.    }catch(ValidateException e ){

  12.        // 验证失败

  13.    }catch(ParseException e ){

  14.        // 解析失败

  15.    }catch(PersistException e ){

  16.        // 入库失败

  17.    }

  18.  }


上述代码就是典型的使用异常来处理业务逻辑.这种方式需要严重的禁止!上述代码最大的问题在于,我们如何利用异常来自动处理事务呢?


然而这和我们的异常中断service没有什么冲突.也并不是一回事。

  • 我们提倡在 业务处理 的时候,如果发现无法处理直接抛出异常即可

  • 而并不是在 逻辑处理 的时候,用异常来判断逻辑进行的状况


改正后的逻辑

 
   
  1.  /**

  2.   * 处理业务消息

  3.   * @param message 要处理的消息

  4.   */

  5.  public void processMessage(Message<String> message) {

  6.    // 处理消息验证

  7.    if(!message.isValud()){

  8.        MessageLogService.log("消息校验失败"+message.errors())

  9.        return ;

  10.    }

  11.    // 处理消息解析

  12.    if(!message.parse()){

  13.        MessageLogService.log("消息解析失败"+message.errors())

  14.        return ;

  15.    }

  16.     // TODO ....

  17.  }


最后俏皮一句:微服务横行的今天,我们在action里面直接写业务处理,也无可厚非。

- END -

 往期推荐:

  • 死磕Java系列:

  1. 深入分析ThreadLocal

  2. 深入分析synchronized的实现原理

  3. 深入分析volatile的实现原理

  4. Java内存模型之happens-before

  5. Java内存模型之重排序

  6. Java内存模型之分析volatile

  7. Java内存模型之总结

  8. J.U.C之AQS简介

  9. J.U.C之AQS:CLH同步队列

  10. J.U.C之AQS同步状态的获取与释放

  11. J.U.C之AQS阻塞和唤醒线程

  12. J.U.C之重入锁:ReentrantLock

……

  • Spring系列:

  1. Spring Cloud Zuul中使用Swagger汇总API接口文档

  2. Spring Cloud Config Server迁移节点或容器化带来的问题

  3. Spring Cloud Config对特殊字符加密的处理

  4. Spring Boot使用@Async实现异步调用:使用Future以及定义超时

  5. Spring Cloud构建微服务架构:分布式配置中心(加密解密)

  6. Spring Boot快速开发利器:Spring Boot CLI

……

可关注我的公众号

640?wx_fmt=jpeg

深入交流、更多福利

扫码加入我的知识星球

640?wx_fmt=png

点击“阅读原文”,看本号其他精彩内容

你可能感兴趣的:(优雅处理你的Java异常)