本文为《spring揭秘》第11章的阅读笔记，该书对spring的基本原理进行了深度剖析，是我目前看过的最好的spring中文资料。
java中的异常层次体系如下图所示：
java exceptions class hierarchy
我们通常将java中的异常类型分为以下两种类型：
通常将java.lang.error和java.lang.runtimeexception及其子类称之为unchecked exception。之所以这么称呼，是因为编译器不会对这些类型的异常进行编译期检查。因为一般关心不到java.lang.error，狭义上来说，将java.lang.runtimeexception暂且称为unchecked exception也可以；
java.lang.exception及其子类，并除去java.lang.runtimeexception分支，统称为checked exception。一旦在方法签名中声明了将会抛出“checked exception”，调用者就必须对这些异常进行处理。
抛开业界对checked exception和unchecked exception的论战不谈，重点看着两类异常的应用场景：
unchecked exception：对应系统中的严重异常情况，这些情况应用程序一般无法恢复，比如数据库挂掉、网络连接中断、服务器崩溃等。所以，unchecked exception异常所提供的信息一般不是为应用程序准备的，而是为系统维护人员准备的。
checked exception：通常用于表明系统中的某些罕见的非正常状态。对于一个业务方法来说，使用错误码（error code）的时代是通过返回-1之类的数字表明一些非正常状态，并要求调用方对这些非正常状态进行处理，而编译器对checked exception的检查可以进一步加强这种契约关系；通常checked exception是可恢复的，也是意料之中的，它提供的信息是面向应用程序的。
对于unchecked exception来说，不管应用抛出何种类型的unchecked exception，最终都需要人进行干预，只要unchecked exception能够提供足够的信息，相应人员就可以进行处理。
当系统中有多个地方可能抛出unchecked exception的时候，在引入fault barrier概念之前，我们可能会在每个调用的最顶层，分别添加异常处理逻辑对其进行处理；不过，unchecked exception可做的事情很少，通常就是记录日志、通知相应人员。所以，这些相同的逻辑实现可以归并到一起进行统一处理，对于系统的fault来说，它实际上就是一种横切关注点（cross-cutting concern）。
因此，我们完全可以实现一个对应fault处理的aspect，让其对系统中所有可能的fault情况进行统一处理，这个aspect就称之为fault barrier。基本的处理模式如下图所示：
exception barrier pattern.jpg
javax.servlet.filter是servlet规范为我们提供的一种aop支持，通过它，我们可以为基于servlet的web应用添加对应的资源访问控制。基于filter的web应用的资源访问控制，仅仅是特定领域的安全检查需求，而通过aop，我们可以为任何类型的应用添加安全支持。
spring security是一套框架，专注于为java应用提供验证和授权功能。跟大多数spring项目类似，spring security的威力在于它具备良好的可拓展性，用于满足各种定制的需求。spring security具备如下特性：
针对验证（authentication）和授权（authentication）的全面和扩展支持；
防止session fixation、点击劫持（clickjacking）和交叉站点请求伪装（cross site request forgery）等各种攻击；
集成servlet api;
可以与spring web mvc集成
aop应用的另一个主要业务场景是为系统透明地增加缓存支持。缓存可以在很大程度上提升系统的性能，但它不是业务需求，而是系统需求。
为了避免需要添加的缓存实现逻辑影响业务逻辑的实现，我们可以让缓存的实现独立于业务对象的实现之外，将系统中的缓存需求通过aop的aspect封装。
<a href="http://www.oracle.com/technetwork/java/effective-exceptions-092345.html">— java exceptions have been the subject of considerable debate in the community. some have argued that checked exceptions in the java language are an experiment that failed. this article argues that the fault does not lie with the java model, but with java</a>