作者：taowen
不知道你用什么來應對程序出錯的情況。從返回錯誤號到返回錯誤對象，從設置全局錯誤號到setjmp longjmp，從使用異常到知道不使用異常，似乎錯誤處理總是一件因為很難考慮，從而不知如何應對，進而往往被忽略的東西。

我們是否需要錯誤處理？答案當然是肯定的。無論你寫的是什么樣的程序，都需要一個很好的品質。對于高性能的系統級別的軟件，我不大清楚那個世界之中應該如何做才能滿足要求。近日研究了一下java中的Exception，也就是高級語言中的Exception，所以對于這種普通應用的錯誤處理稍微比以前多了解了一點，在這里和大家分享一下。

我首先要區分的是錯誤出現時間：
1 開發的時候
2 發布了之后

對于這兩個情況我們處理的辦法是完全不一樣的。對于開發的時候，Exception出現了，我們會去找代碼中的錯誤，然后通過對代碼的修改把出錯的地方調試好。對于發布了之后，我們對于那個時候的錯誤是無法預期的。因為原因是無法與其的，所以我們不能通過修改代碼達到修正錯誤的目的。這個時候利用的就是Exception的層次，通過對可疑代碼進行try，catch可能的Exception，并且通過Exception的類型大概的了解了出錯的原因，然后根據這么一點點的信息進行可能的應對。

我們應對兩種時間出現的Exception的辦法是截然不同的，而Exception在這兩種場合下的職責也是不同的。對于開發的時候，Exception主要的目的是讓程序員了解錯誤是出在了哪里，是怎么一回事。對于發布了之后的情況，Exception主要是通過其自身的類型，選擇程序員預先猜測的catch。然后catch的代碼之中有可能是retry這個操作，或者拋出一個比較明確的對話框給用戶，讓用戶去面對出錯的場景，因為出錯的時候是他在場，而不是程序員在場。

區分了這兩種情況，我們也就把Exception分成了兩種，前一種需要的是對于程序員有意義的描述，不一定需要一個類層次。第二種是要讓try catch的代碼進行分類捕捉，一般需要一個類層次。

區分了錯誤發生的時間之后，我們來關注錯誤發生的原因：
從我最近的觀點來說，主要要區分的就是錯誤發生的職責到底是哪個方面的，使調用方，還是執行方。Exception是從執行方給調用方的，對于Exception的類型，描述都是由執行方給出的，因為錯誤是處在執行方進行執行的過程中的，只有它才知道到底是在一個什么樣的情況下發生了一個什么樣的錯誤。
然后我們就把自己比作一個執行方，我們在遇到了一個出錯的情況的時候，我們會怎么辦。所謂出錯，也就是程序執行不下去了，為什么執行不下去了，1 調用方沒有滿足執行方要正確執行的條件，這些條件可以用一些if語句或者assert來具體表現。 2 在執行方進行“正?！辈僮鞯臅r候（暗含的意思就是調用下層代碼的時候沒有違背它的契約），執行方要調用的下層代碼出現了問題，而執行方根本不知道如何處理。在這兩種情況下，對于第一種，我們理解這種錯誤就是程序員的bug，因為他在寫代碼的時候沒有滿足執行方給出的契約。對于第二種，我們理解為真正的異常，雖然有可能這個異常只是下層代碼中的一個bug，但是對于調用下層代碼的執行方來說，我滿足了你要的條件，你還是拋出了Exception，我干不下去了，然后它就把異常傳遞，或者自己進行一些可能的嘗試。
所以對于所有的調用方來說，執行方就是會給出兩種Exception，一種反映的是它能肯定的程序員的bug， 一種是它不能肯定，情況不明的異常。對于第一種，我們沒得選擇就是在編寫程序的時候及早發現，如果沒有處理，在發布之后對于這種異常只能給出一個“程序內部錯誤”。對于第二種，我們應該用try catch進行一些嘗試，也可能是給用戶一個很好的提示，如果不是最終的GUI代碼，則還可以選擇把異常繼續上報。

最后：
其實，這樣說來第一種異常就不能說是異常，應該在發現的時候就中斷程序，提示開發者。這個就是Assert的行為。也就是說，異常/Exception 不應該用來表示程序員編寫的代碼對于契約的違背，而且程序員也不一定需要一個Exception才能知道自己哪里搞錯了，日志，Assert窗口，別的什么的，都行。為了程序員方便調試，為了程序員能夠知道更多信息，這個目的去設計一個異常類層次是不值得的。