[.NET Concept]例外處理使用時機


image



看到網友Bill叔寫了一連串的Try Catch的探討,這邊我也大概的整理一下我對例外處理使用時機的認知。





我常會看到很多我覺得不適當的例外處理寫法,大概可列出下面幾種:




  • 例外處理只為了秀出Exception本來包含的訊息,完全不改成自己格式就直接秀出



像下面這種寫法秀出的資訊少到完全看不出問題點,且可能讓程式在不正常的條件下繼續執行。這樣的寫法倒不如不要使用例外處理直接讓.NET程式預設的例外視窗彈出,資訊還較為豐富,不然就是自行客制處理例外訊息的對話框,讓例外訊息對話框變成自己想要的樣子。而且通常例外所提供的訊息並不適合給使用者看,一來對於使用者並不友善,二來也多半沒有做多語的支援。




Try

Catch ex As Exception
MsgBox(ex.Message)
End Try








  • 例外處理後又讓例外外擴



像下面這種寫法其實倒不如不要寫例外處理,例外本身就會外擴。除非攔截例外是為了做些記錄或是處理,不然不建議攔截後外擴,大家應該都知道例外處理攔截到例外的Overhead是很大的,若是一個例外發生後被攔截後外擴,連續發生了好幾次,不難推測這個Overhead會變成本來的好幾倍。




Try

Catch ex As Exception
throw ex
End Try







若是需要在例外處理中攔截例外做些處理後再外擴,也該改用throw去取代throw ex,這樣速度會比較快,也不會去變更到呼叫堆疊。






  • 例外處理只為了吞掉例外



最糟的寫法是直接用例外處理來吞掉例外,當然有時候這樣的情況會無法避免,但起碼要知道自己在做甚麼,並盡可能的避免,畢竟這樣的處理方式不夠嚴謹,且例外處理的耗費是很重的,若頻繁執行到這個區塊,效能會大幅的降低。




Try

Catch ex As Exception
End Try







其實就我個人而言,我在程式中是很少使用Try Catch的,因為使用了Try Catch的話,在Debug時若程式當掉,Visual Studio會自動把程式跳到Catch的位置上(目前我電腦上連Catch都不會停,完全感覺不出例外發生),而若無法從Catch參數的資訊抓到問題點的話。自己還需要再重新Debug一次,從Try的位置一步一步的追到問題點。





若不使用Try Catch的話,則當程式當掉時,Visual Studio會自動跳到出問題的程式那行,抓到問題的速度其實還比較快。



image





對於例外處理的使用時機,通常我是會看說這段程式是否可能會有例外發生,該例外的彈出是否是合理的。若例外的彈出合理且該例外的彈出需要秀出對應的訊息告知使用者,此時我就會使用Try Catch。會這樣做是因為我覺得例外有兩種,一種是給User看的例外、一種是給開發員看的例外。





給開發員看的例外主要是告知開發人員程式的寫法有誤,這類的例外本來就不該在執行階段發生,而是應該在開發時處理掉。那麼可能有人會問要是忘了處理乾淨呢?沒關係,例外發生時程式會彈出預設的例外視窗,讓程式員可以很快的把這錯誤給修正掉。



image





而給User看的例外則應該要能在執行階段依照例外給予不同的指示訊息,幫助使用者排除問題。這類型的例外我才會做例外處理。



image