本文為《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>