從接觸異常開始我就弄不明白她，不會用她，想在系統中是異常機制發揮的淋漓盡致，進行了很多嘗試，利用異常控制程式流程，利用異常做數字的判斷函式，利用異常消除系統中可能出現的惱人的異常提示框，為了更好了利用異常看了很多關於異常的文章，直到有一天看到了一句話——“永遠不要去處理你不知道怎麼處理的異常”，這才恍然大悟，感覺自己一直在用強大的異常機制幹一些旁門左道的是事，更談不上理解異常在程式中的地位和意義，異常其實一種報告機制，“她以一種不可迴避的方式報告程式中所出現的問題”，她幫助程式設計師走向正確的道路，她忠實的向程式設計師提供錯誤報告，她希望有誰能重視並處理掉她報告的問題，哈，真不敢想象，沒有了異常機制該如何編制高質量的程式！下面就個人的理解和看法瞎說幾句，敬請各位批評指正，不勝感激！
異常的工作原理，在有問題的地方產生異常，馬上停止當前的工作，轉向異常處理程式碼，如果找不到異常處理程式碼，就會見異常向一層彙報，上一層接到異常會做同樣的事，轉向異常處理程式碼，或者再將異常向上彙報，這樣逐層間錯誤傳遞出去，直到有一層處理了異常或是一直報告給程式的使用者——使用者。這個層就是呼叫棧，當用戶A執行程式B，B從函式C開始執行，呼叫函式D，再呼叫函式E，再呼叫函式F，這時F出現了異常，那麼這個異常的呼叫棧就是A(棧底)—〉B—〉C—〉D—〉E—〉F(棧頂)，這個異常就會沿著這個棧從棧頂開始向棧底的方向報告，如果在函式C中有對這個異常的處理程式碼，那麼這個異常的報告鏈就是F—〉E—〉D—〉C。可以看出，如果在完整的呼叫棧中沒有處理這個異常的程式碼，使用者A就成了異常報告的終點，向windows介面系統，會彈出一個惱人的訊息對話方塊哈。
那麼使用者A向誰報告呢，哈哈，這個已經不屬於程式的範圍了，感覺用會對程式而言好像上帝一樣，訴說痛苦已經讓上帝都聽到了，就心滿意足了哈哈，看來程式真虔誠哈哈。對於異常這個特性，也可以比喻成下屬向上級報告問題，如果下屬知情不報，問題就嚴重了，你要是領導知道下屬是這樣的八成就踢了他，相反如果你有一個報告機制健全的下屬隊伍，哈哈你就威風了。日本企業文蛤中有個宗旨——聯絡，商談，報告，其實就是想讓員工都具有向上級彙報的習慣。現在再看看程式，哈哈，你不用給她們灌輸什麼企業文化，不用她們講述什麼報告的重要性，她們本身就是忠實報告的，如果把程式設計師比作企業老總，那麼程式就是訓練一隊有素的員工。
怎樣處理異常。在這裡有個原則就是“永遠不要去處理你不知道怎麼處理的異常”，
也就是隻處理你知道如何處理的異常，對那些你不知道的異常必須廣開言路，並積極地向上級彙報。什麼叫知道如何處理呢？先說一下處理異常有哪些方式，大體有，彈出提示訊息框(這個訊息框不同於那個惱人的異常報告訊息框，她是捕獲異常後，根據處理的具體環境程式設計師主動編寫的友好的提示訊息框)，記錄錯誤日誌，吞掉，做善後工作等等，那麼出現異常時就要站在出現異常的`模組的立場上考慮一下我應該選擇哪種處理方式呢？如果不能做出選擇就選擇不處理，即向上級報告。
舉個例子，函式Fun1是建立並返回一個活動的資料連線物件的方法，他接受一個數據庫連線字串，如果呼叫者（上級）給他一個錯誤的連線字串，這時Fun1建立不了連線物件，產生了一個建立不了連線物件的異常，那麼這時他應該怎樣處理這個異常呢？彈出友好的訊息框？說什麼友好，Fun1根本就不知道是什麼原因使他接收到了錯誤的連線字串，彈一個“連線字串有誤”，使用者肯定都有殺你的心，這個提示和使用者的業務邏輯有嘛關係！記錄錯誤日誌，這個還行，但是記錄下來的文字無非就是“連線字串有誤，連線字串是：SQL……”，好點的話，從連線字串中看出了問題，一般情況下還得根據程式碼上下文去找問題原因。這個方式不是不行是不好。吞掉，哈哈開什麼玩笑，你既建立不了連線，又不吱一聲，想讓呼叫者瘋了呀，這個肯定不行。做善後工作，行，確實應該清理一下現場，