背景
软件开发过程中，不可避免的是需要处理各种异常，所以代码中就会出现大量的try {...} catch {...} finally {...} 代码块，不仅有大量的冗余代码，而且还影响代码的可读性。比较下面两张图。丑陋的 try catch 代码块
优雅的Controlle
Spring在3.2版本增加了一个注解@ControllerAdvice，可以与@ExceptionHandler、@InitBinder、@ModelAttribute%20等注解注解配套使用，对于这几个注解的作用，这里不做过多赘述，若有不了解的，可以参考Spring3.2新注解@ControllerAdvice，先大概有个了解。不过跟异常处理相关的只有注解@ExceptionHandler，从字面上看，就是%20异常处理器的意思，其实际作用也是：若在某个Controller类定义一个异常处理方法，并在方法上添加该注解，那么当出现指定的异常时，会执行该处理异常的方法，其可以使用SpringMVC提供的数据绑定，比如注入HttpServletRequest等，还可以接受一个当前抛出的Throwable对象。但是，这样一来，就必须在每一个Controller类都定义一套这样的异常处理方法，因为异常可以是各种各样。这样一来，就会造成大量的冗余代码，而且若需要新增一种异常的处理逻辑，就必须修改所有Controller类了，很不优雅。那就定义个类似BaseController的基类，这样总行了吧。这种做法虽然没错，但仍不尽善尽美，因为这样的代码有一定的侵入性和耦合性。简简单单的Controller，为啥非得继承这样一个类呢，万一已经继承其他基类了呢。大家都知道Java只能继承一个类。那有没有一种方案，既不需要跟Controller耦合，也可以将定义的%20异常处理器%20应用到所有控制器呢？所以注解@ControllerAdvice出现了，简单的说，该注解可以把异常处理器应用到所有控制器，而不是单个控制器。借助该注解，可以实现：在独立的某个地方，比如单独一个类，定义一套对各种异常的处理机制，然后在类的签名加上注解@ControllerAdvice，统一对%20不同阶段的、不同异常%20进行处理。这就是统一异常处理的原理。注意到上面对异常按阶段进行分类，大体可以分成：进入Controller前的异常%20和%20Service%20层异常，具体可以参考下图：
消灭95%以上的%20try%20catch%20代码块，以优雅的%20Assert(断言)%20方式来校验业务的异常情况，只关注业务逻辑，而不用花费大量精力写冗余的%20try%20catch%20代码块。
在定义统一异常处理类之前，先来介绍一下如何优雅的判定异常情况并抛异常。
Assert(断言)%20替换%20throw%20exception想必%20Assert(断言)%20大家都很熟悉，比如%20Spring%20家族的%20org.springframework.util.Assert，在写测试用例的时候经常会用到，使用断言在编码的时候有一种非一般丝滑的感觉，比如：
有没有感觉第一种判定非空的写法很优雅，第二种写法则是相对丑陋的%20if%20{...}%20代码块。那么%20神奇的%20Assert.notNull()%20背后到底做了什么呢？下面是%20Assert%20的部分源码：
可以看到，Assert%20其实就是把%20if%20{...}%20封装了一下，是不是很神奇。虽然很简单，但不可否认的是编码体验至少提升了一个档次。那么能不能模仿org.springframework.util.Assert，也写一个断言类，不过断言失败后抛出的异常不是IllegalArgumentException%20这些内置异常，而是自己定义的异常。下面来尝试一下。
评论