程式開發中異常的理解和認識

來源:互聯網
上載者:User
從接觸異常開始我就弄不明白她,不會用她,想在系統中是異常機制發揮的淋漓盡致,進行了很多嘗試,利用異常控製程序流程,利用異常做數位判斷函數,利用異常消除系統中可能出現的惱人的異常提示框,為了更好了利用異常看了很多關於異常的文章

直到有一天看到了一句話——“永遠不要去處理你不知道怎麼處理的異常”,這才恍然大悟,感覺自己一直在用強大的異常機制幹一些旁門左道的是事,更談不上理解異常在程式中的地位和意義,異常其實一種報告機制,“她以一種不可迴避的方式報告程式中所出現的問題”,她協助程式員走向正確的道路,她忠實的向程式員提供錯誤報表,她希望有誰能重視並處理掉她報告的問題,哈,真不敢想象,沒有了異常機制該如何編製高品質的程式!下面就個人的理解和看法瞎說幾句,敬請各位批評指正,不勝感激!

異常的工作原理,在有問題的地方產生異常,馬上停止當前的工作,轉向異常處理代碼,如果找不到異常處理代碼,就會見異常向一層彙報,上一層接到異常會做同樣的事,轉向異常處理代碼,或者再將異常向上彙報,這樣逐層間錯誤傳遞出去,直到有一層處理了異常或是一直報告給程式的使用者——使用者。這個層就是調用棧,當使用者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……”,好點的話,從連接字串中看出了問題,一般情況下還得根據代碼上下文去找問題原因。這個方式不是不行是不好。吞掉,哈哈開什麼玩笑,你既建立不了串連,又不吱一聲,想讓調用者瘋了呀,這個肯定不行。做善後工作,行,確實應該清理一下現場,免得浪費資源,但是還是沒吱一聲,所以這個方式做的不徹底。沒招了,哈,其實上面的分析給我們指明了一條路,協助我們祛除了錯誤的選擇,這條路就是向上彙報,或是不加任何出來代碼,或是記錄日誌,做些善後,再重新將異常拋出。

那麼什麼時候就知道怎樣處理異常了,這就得看實際的情況和使用者的要求了,這句話等於沒說,就像其他的標題醒目但給出的結論卻模稜兩可文章一樣,哈哈,這裡可以給幾個建議,

1,一般地,底層模組或是方法中不要處理異常,

2,編寫公用模組、DLL等是,不能採用彈出對話方塊等依賴於平台,架構的方式處理異常,

3,編寫公用模組、DLL等時,必須在使用文檔中註明每個方法屬性可能拋出的異常。

4,永遠不要寫 try 這樣的語句。

{ } catch(Exception) { o nothing } 自訂異常。明白了異常的原理和機制後,就可以自己定義異常了,這樣的實踐往往在編寫控制項、公用模組、DLL等的時候,用錯誤編號在網上搜尋一下,能找出一大堆關於錯誤碼的描述。其中大多數是M(icro)S(oft)制定的,MS 從作業系統到各種各樣的架構都有對各種異常的編號,對每種異常做出了詳細的定義,如果你還用過像Spread等商業控制項,也可以看到他裡邊的各種各樣的異常定義,也就是說我們自己也可以定義異常,在必要的時候,這樣就可以讓自己寫的模組也加入到訓練有素的員工隊伍中了。至於如何定義異常,具體的編成語言有具體的做法,比如C#中指定一異常一個從Exception繼承來的類,VB中異常是個全域變數等等,參見感興趣語言的文法指南就可以了。

對異常的重新認識,一直以來許多人都認為異常是非常可怕的,可惡的,她是錯誤的化身,她有惱人的彈出對話方塊,弄得使用者跟凶煞惡神似的哈哈,其實這些都是誤解,異常一直默默地忠實的報告著程式中出現的嚴重的不可迴避的問題,她為了程式、系統的正確性、嚴謹性呼喚你,希望你重視這些問題,希望你用智慧解決這些問題,她是多麼的可愛,又是多麼的高尚,從來沒有因為對她的誤解而放棄自己的使命……(哈哈,扯淡,煽情了……)。異常很重要,我們更好學會如何去使用她。



相關文章

Alibaba Cloud 10 Year Anniversary

With You, We are Shaping a Digital World, 2009-2019

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。