1.異常處理的好處在絕大多數的情況下都是大於壞處,請儘量使用異常處理.
2.如果要針對單獨一種異常進行了try...catch處理後,最好外面再要外包一層try...catch去捕捉未知的異常(或者用一個try,多個catch,而最後一個catch就是用來catch未知異常),因爲你永遠都不不能保證你的程序在哪裏拋出何種異常,正如引用文章那個中所說的OutOfMemoryExcetpion等異常是很常見的,想象一下有過萬行的數據轉化成Excel報告這樣的情景,拋出這個異常就不足爲奇了,因爲我就遇到過.^_^
3.try...catch要包裝儘量少的代碼嗎? 顯然,沒有發生異常的時候,基本是沒有什麼性能損失的,決定要不要這樣做,其實得看情景的,例如一個很簡單可能發生除零錯誤的代碼塊,就可以很明確的只try...catch這一段,讓人更明確這裏到底會出什麼問題,同時告訴人家你已經對預計中的問題都做了處理了.但這種完美的情況基本上都是不存在的,所以說盡量try更多的代碼,catch更多的異常顯得更重要,因爲一些已經知道的異常,爲什麼還要你try呢?何不自己就靜悄悄的處理掉呢?是吧 ^_^
4.底層的框架類庫儘量少用try...catch嗎? 底層的框架類庫通常比較通用,性能的要求也比較高,所以只在總接口中使用try...catch?這也許是很多人的一些誤解,他們或者會認爲有了總接口中做了異常捕捉就可以萬事大吉,因爲異常是會一層一層網上拋出來的,所以有異常可定能捕捉到.但實際中如果這樣操作會出現很多問題.因爲這樣很不利於程序的排錯,特別是在一些時間比較緊要求並行開發(類庫和業務代碼同時進行開發)的項目中,到了代碼會師那一刻,代碼有bug,排錯就很困難,因爲catch到已經是穿過幾個時空後的原始人,都不知道他是來自那個世紀的^_^,所以其實底層更需要try...catch.
5.catch中不要包含業務邏輯! 有些朋友喜歡在異常處理模塊中把業務包含進去,但這樣其實有很大的隱患的. 我曾經看到過這樣的一個例子,有個業務邏輯是要判斷用戶是否設置了某個時間,然後用這個時間進行其他處理,這裏那位哥們使用一個省勁的方法,就是先把取出來的值做時間轉換,能轉就是有定義,不能轉拋出異常就判斷用戶沒有定義這個時間,這樣做初初看上去好像問題也不大,但是日後如果客戶要投下業務變動的原子彈,後果是如何,大家想像一下就知道,這裏引用句經典話,"誰用誰知道啊" ^_^
6.儘量"throw;",不要"throw e;". 這兩者有什麼區別呢,如果使用"throw e;"只是單純把捕捉到的異常拋出來,其實還有一些存在與堆棧中的信息沒有被拋出來,所以throw出來的東西是經過過濾的,如果大家是要向上一層進行throw,就要來得徹底點,不然又可能會給排錯加上一層不該有的迷霧的哦 ^_^
7.catch中如果要寫log,請把當前StackTrace也要拉進來. 因爲把StackTrace記錄下來,可以獲取一些對排除異常很有幫助的信息,例如引發這個異常的調用的事件和函數列表等,想象一個經過多次throw才catch的異常,有這個瓜藤,就不怕摸不着瓜啦,是吧 o(∩_∩)o
參考文章:關於.NET的異常處理的幾個誤區
