（一）在什么場景下加Try-Catch機制
1）以業務邏輯功能為單位，在最上層加Try-Catch機制。為什么要這樣做呢？這主要是增加程序的健壯性，防止因拋出異常過多，導致程序崩潰。
try
{
//業務邏輯功能
//......
}
catch
(Exception ex)
{
//記錄日志
//......
}
2）底層代碼，在可能出錯的地方加Try-Catch機制，用Catch偵測具體的異常，然后就具體的異常，采取相應的解決方案。
try
{
sent += sendSAEA.AcceptSocket.Send(buffer, sent, size - sent, SocketFlags.None);
}
catch
(ObjectDisposedException ex)
//Socket 已關閉
{
break
;
}
catch
(SocketException ex)
{
//socket異常，等待后繼續嘗試發送
Thread.Sleep(
this
.socketListenerSettings.MSDelayForNextSend);
}
catch
(Exception ex)
{
this
.SaveLog(
"Send方法出錯，錯誤描述為："
+ ex.Message.ToString());
break
;
}
3）底層代碼，在需異常追蹤時加Try-Catch機制，在Catch塊中拋出自定義異常，調試時可迅速定位到錯誤代碼段。
try
{
//底層代碼
//......
}
catch
(Exception ex)
{
throw
new
Exception(
"xxx方法出錯，描述："
+ ex.Message.ToString());
}
（二）Try-Catch機制注意點
1）Try-Catch機制會將異常屏蔽掉，在解決異常時，您可以根據具體的異常執行相應的解決方案，也可以記錄錯誤日志，用於異常追蹤，還可以直接拋出自定義異常。在眾多選擇中，請牢記一條：必須根據具體的應用場景，具體分析。比如，我們寫一個程序實現ATM機取現功能，首先，驗證用戶的合法性，其次，驗證用戶本次操作的合法性，最后，完成用戶操作。我們在以上三個操作都加上Try-Catch機制，如果此時第一個操作出現異常，您如果只是記錄一下日志，將此異常屏蔽掉，將會造成災難性的后果。
2）不能濫加Try-Catch機制，Try-Catch機制在一定程度上會損耗或影響性能，建議有以下幾點准則：
1.盡量給CLR一個明確的異常信息，不要使用Exception去過濾異常
2.盡量不要將try…catch寫在循環中
3. try盡量少的代碼，如果有必要可以使用多個catch塊，並且將最有可能拋出的異常類型，書寫在距離try最近的位置
4.不要只聲明一個Exception對象，而不去處理它。這樣做白白增加了Exception Handing Table的長度。
5.使用性能計數器實用工具的“CLR Exceptions”檢測異常情況，並適當優化
6.使用成員的Try-Parse模式，如果拋出異常，那么用false代替它