很多人喜歡用Try...Catch把每一個方法都包裹起來，可是真的有必要么？
為什么要這樣做？我估計是大家被BUG嚇怕了，生怕生產環境出現各種莫名其妙的錯誤，比如最經典的NullReferenceException,可問題是你用Try...Catch包裹起來后錯誤是不會爆出來了，但是執行結果是你想要的么？恐怕bug還在那里，只是經過你的Try...Catch之后，bug更加難找了，原本你用vs調試起來，直接就斷在了異常發生的地方，現在呢？你得一步步跟蹤過去。
這不是最主要的問題，最重要的問題是你在開發過程中隱藏了bug,如果當時你沒加這個Try...Catch,恐怕你早就發現這個bug了，因為程序壓根就跑不下去。
異常信息應該由最上層的框架捕獲，比如MVC中有ExceptionFilter,你可以在這里記錄詳細日志，別把黃頁拋給用戶就可以了。我想寫一個Try...Catch的場景，但是居然一下子想不出來一個很好的場景，因為真真需要寫Try...Catch的場景是很少的，你一旦想寫Try...Catch，首先想想你是不是在故意隱瞞Bug.
反而我鼓勵大家寫Throw exception,比如這種場景:
public void Register(string userName,string password)
{
if(string.IsNullOrEmpty(userName))
throw new InvalidDataException("user name can not be empty");
if(string.IsNullOrEmpty(password))
throw new InvalidDataException("password can not be empty");
//....
}
public void Register(string userName,string password)
{
try
{
//....
}
catch (Exception)
{
}
}
理論上，雖然UI做了各種校驗，我們寫的Register任然保持對參數的不信任，繼續拋異常而不是Try..Catch,這樣你是不是能提前發現UI沒有校驗的bug呢？
追加內容：很多同學對此文的結論難以接受，最有疑問的就是“Try...catch可以記錄日志，捕獲異常的詳細信息，不會讓程序掛掉", 我需要重申的是:Try...Catch的作用不是用來記錄日志的，任何框架都在頂層提供了捕捉異常的方案(純類庫除外)：
以.NET為例：
-
Winform,可以:
AppDomain.CurrentDomain.UnhandledException +=new UnhandledExceptionEventHandler(UnhandledExceptionFunction);
- Asp.net，可以在Application_Error()方法里捕獲異常
- MVC,可以寫ExceptionFilter
- WebApi,可以寫ExceptionHandler
這里面拿到的Exception都是帶整個Stack記錄的，你可以用Log4記錄下來，並不是有的同學說的只會拿到e.message這樣
建議：少寫Try...Catch,喜歡寫Try...Catch的朋友注意：你那90%的Try...Catch都是在坑隊友