Java提供了兩類主要的異常:runtime exception和checked exception。checked 異常也就是我們經常遇到的IO異常，以及SQL異常都是這種異常。對于這種異常，JAVA編譯器強制要求我們必需對出現(xiàn)的這些異常進行catch。所以，面對這種異常不管我們是否愿意，只能自己去寫一大堆catch塊去處理可能的異常。

   但是另外一種異常：runtime exception，也稱運行時異常，我們可以不處理。當出現(xiàn)這樣的異常時，總是由虛擬機接管。比如：我們從來沒有人去處理過NullPointerException異常，它就是運行時異常，并且這種異常還是最常見的異常之一。

    以前一直沒仔細想過出現(xiàn)運行時異常了系統(tǒng)會怎樣工作，最近在一個模塊排錯時，才無意中發(fā)現(xiàn)了系統(tǒng)是如何處理運行時異常。出現(xiàn)運行時異常后，系統(tǒng)會把異常一直往上層拋，一直遇到處理代碼。如果沒有處理塊，到最上層，如果是多線程就由Thread.run()拋出，如果是單線程就被main()拋出。拋出之后，如果是線程，這個線程也就退出了。如果是主程序拋出的異常，那么這整個程序也就退出了。運行時異常是Exception的子類，也有一般異常的特點，是可以被Catch塊處理的。只不過往往我們不對他處理罷了。

    也就是說，你如果不對運行時異常進行處理，那么出現(xiàn)運行時異常之后，要么是線程中止，要么是主程序終止。如果程序的退出剛好是你期望的結果，那就萬事OK了。

   但最近我在項目卻遇的問題，恰恰是這因為沒有對運行時異常進行處理，而導致程序在運行一小段時間后就當了。事情是這樣的，由于寫程序時我對多線程的并發(fā)處理不太會，也就把一個模塊寫成了單線程的，由它來循環(huán)處理一個數(shù)據(jù)隊列。但沒想到隊列里面的數(shù)據(jù)有一些與預期的格式不一樣，處理這樣的數(shù)據(jù)時，程序就拋出了運行時異常。由于沒有對異常進行處理，這個異常也就拋到了Thread.run()。最后這個處理線程肯定是被終止了，隊列里面的數(shù)據(jù)也就不會再有程序去處理了。這個結果顯然不是我想要的，隊列里面出現(xiàn)異常數(shù)據(jù)了，正常的處理應該是把異常數(shù)據(jù)舍棄，然后記錄日志。不應該由于異常數(shù)據(jù)而，影響下面對正常數(shù)據(jù)的處理啊。

    所以最后我在程序的循環(huán)處理模塊，里面加了一個catch處理，來撲捉所有的異常，決不讓這個處理線程退出，要知道我的所有數(shù)據(jù)還要依靠他來處理呢 （^_^ )。在這個場景這樣處理可能是一個比較好的應用，但并不代表在所有的場景你都應該如此。如果在其它場景，遇到了一些錯誤，如果退出程序比較好，這時你就可以不太理會運行時異常，或者是通過對異常的處理顯式的控制程序退出。

   知道了虛擬機怎么處理運行時異常，也更進一步理解了Sping對Hibernate的封裝了。由于Hibernate是和數(shù)據(jù)庫打交道，所以總是要拋出一些亂七八糟的checked異常，平時我們根本不想catch這些異常。因為這些異?？偸前汛a弄的亂亂的，搞的到處都是try{} catch(){}塊，并且常常加了catch塊，也并不能把程序從異常中恢復過來（異常處理的目標之一就是為了把程序從異常中恢復出來）。為了通過編譯器的檢查，程序員被迫加上了catch塊，往往這些catch并沒有發(fā)揮他應有的作用，反而帶來了很大的不便。所以Spring對Hibernate封裝時就把Hibernate的異常進行了封裝，全部封裝成運行時異常了。也就是Spring來撲捉Hibernate拋出的異常，然后Spring把異常轉換成Spring自己定義的運行時異常再拋出。這樣我們在編碼時使用Spring來調用Hibernate時，可以不用catch塊來處理一些不必要的異常。當然你確實要是想處理，也可以通過添加cathc塊去處理異常。不過這個時候，你的Catch就要撲捉運行時異常了，而不是一般的checked異常了。