原博客地址： http://blog.csdn.net/abc19900828/article/details/39497631
使用spring難免要用到spring的事務管理，要用事務管理又會很自然的選擇聲明式的事務管理，在spring的文檔中說道，spring聲明式事務管理默認對非檢查型異常和運行時異常進行事務回滾，而對檢查型異常則不進行回滾操作。
那麼什麼是檢查型異常什麼又是非檢查型異常呢？最簡單的判斷點有兩個：
1.繼承自runtimeexception或error的是非檢查型異常，而繼承自exception的則是檢查型異常（當然，runtimeexception本身也是exception的子類）。
2.對非檢查型類異常可以不用捕獲，而檢查型異常則必須用try語句塊進行處理或者把異常交給上級方法處理總之就是必須寫代碼處理它。所以必須在service捕獲異常，然後再次拋出，這樣事務方纔起效。
結論：
在spring的事務管理環境下，使用unckecked exception可以極大地簡化異常的處理，只需要在事務層聲明可能拋出的異常（這裏的異常可以是自定義的unckecked
exception體系），在所有的中間層都只是需要簡單throws即可，不需要捕捉和處理，直接到最高層，比如UI層再進行異常的捕捉和處理
在service類前加上@Transactional，聲明這個service所有方法需要事務管理。每一個業務方法開始時都會打開一個事務。
Spring默認情況下會對運行期例外(RunTimeException)進行事務回滾。這個例外是unchecked
如果遇到checked意外就不回滾。
如何改變默認規則：
1 讓checked例外也回滾：在整個方法前加上 @Transactional(rollbackFor=Exception.class)
2 讓unchecked例外不回滾： @Transactional(notRollbackFor=RunTimeException.class)
3 不需要事務管理的(只查詢的)方法：@Transactional(propagation=Propagation.NOT_SUPPORTED)
注意： 如果異常被try｛｝catch｛｝了，事務就不回滾了，如果想讓事務回滾必須再往外拋try｛｝catch｛throw Exception｝。
一個統一的異常層次結構對於提供服務抽象是必需的。 最重要的就是org.springframework.dao.DataAccessException以及其子類了。 需要強調的是Spring的異常機制重點在於應用編程模型。與SqlException和其他數據存取API不同的是:
Spring的異常機制是爲了讓開發者使用最少, 最清晰的代碼。DataAccessException和其他底層異常都是非檢查性異常(unchecked exception)。 spring的原則之一就是基層異常就應該是非檢查性異常. 原因如下:
1. 基層異常通常來說是不可恢復的。
2. 檢查性異常將會降低異常層次結構的價值.如果底層異常是檢查性的, 那麼就需要在所有地方添加catch語句進行捕獲。
3.try/catch代碼塊冗長混亂, 而且不增加多少價值。
使用檢查異常理論上很好, 但是實際上好象並不如此。
Hibernate3也將從檢查性異常轉爲非檢查性異常。
