只捕捉你能處理的異常
通常，一些型別的異常可以處理，但是另一些型別的異常不能處理。例如，試圖開啟乙個正在使用的檔案來進行獨佔式的讀/寫訪問，會引發乙個system.io.ioexception，因為檔案已經在使用了。通過捕捉這種型別的異常，**可以向使用者報告該檔案正在使用，並允許使用者選擇取消或者重試。只有那些已知對車的異常才應捕捉。其他異常型別應該留在棧中較高的呼叫者去處理。
不要隱藏你不能完全處理的異常
新手程式設計師常犯的乙個錯誤是捕捉所有的異常，然後假裝什麼都沒有發生，而不向使用者報告未處理的異常。這有可能導致嚴重的系統問題逃過檢測。除非**採取現實的行動來處理乙個異常，或者顯示的確定乙個異常無害，否則catch塊應當重新引發異常，而不是在捕捉了之後在呼叫者面前隱藏他們。尤其要注意的是catch(system.exception)和常規catch塊應放在呼叫棧中較高的位置，除非你決定在塊中重新引發異常
盡可能的少使用system.exception和常規catch塊
幾乎所有的異常都是從system.exception派生的。然而，處某些system.exception的最佳方式是不對它們進行處理，或者盡快以正常的方式關閉程式。例如，想system.outofmemoryexception這樣的異常是無法恢復的，所以最佳對策就是關閉應用程式。相應的catch塊只應執行清理或緊急**（比如儲存任何易失的資料），然後馬上關閉相應的應用程式或者使用throw；語句重新引發異常。
避免在呼叫棧較低的位置報告或記錄異常
新手程式設計師傾向於異常一發生就記錄它，或者向使用者報告它。然而，由於當前正處在呼叫棧中較低的位置，而這些位置很少能夠完整的處理異常，所以會重新引發異常。像這樣的catch塊不應該記錄異常，也不應該向使用者報告。假如異常被鉅鹿，然後又被重新引發（呼叫棧中較高的呼叫者可能做同樣的事），就會造成重複出現的異常記錄項。更糟的是，向使用者顯示異常可能並不匹配應用程式。例如，在乙個windows應用程式中，使用system.console.writeline()，使用者永遠看不到顯示的內容。類似的，在無人值守的命令列程序中顯示乙個對話方塊，可能根本就不會被別人看到，而且可能使應用程式凍結在這個位置。與日誌記錄和異常有關的使用者介面應該保留到呼叫棧中較高的位置。
在乙個catch塊中可以使用throw；而不是throw 《異常語句》語句
可以在乙個catch塊中重新引發異常。例如，在catch（argumenhtnullexception exception）的實現中，可以包含對throw exception的呼叫。然而重新引發異常，會將棧追蹤重置為重新引發的位置，而不是原始引發的位置。所以，假設如果不是要重新引發乙個不同型別的異常，或者不是要故意隱藏原始呼叫棧，就應該使用throw ； 語句，允許相同的異常在呼叫棧中向上傳播。
重新引發不同的異常是要小心
在乙個catch塊的內部，假如你重新引發乙個不同的異常，那麼不僅會重置引發點，還會隱藏原始異常。為了保留原始異常，需要重新設定新異常的innerexception屬性（該屬性通常可以通過構造器來賦值）。通常只應在以下情況下才重新引發乙個不同的異常
a）更改異常型別可以更好的澄清問題
例如，在對logon（user user）的乙個呼叫中，假如遇到使用者列表檔案不能訪問的情況，那麼重新引發乙個不同的異常型別，要比引發system.io.ioexception更合適。
b）私有資料是原始異常的一部分
在上面的例子中，假如檔案路徑包含在原始的system.io.ioexceptionzhong ,就會暴露敏感的系統資訊，所以應該使用其他異常型別來封裝它（當然，前提是原始異常沒有設定innerexception屬性）。
c）異常型別過於具體，以至於呼叫者不能恰當的處理
例如，不要引發特定於某個資料庫系統的異常。相反，可以使用乙個較為廣泛的異常，以避免在呼叫棧比較高的位置寫特定於某個資料庫的**
Flex異常處理原則
flex異常處理原則 1.有一條清楚的訊息表明已經發生了乙個錯誤，不能簡單地try.catch乙個異常，而不加以處理。2.有乙個唯一的錯誤號，他可以據此訪問可方便獲得的客戶支援系統 3.問題快速得到解決，並且可以確信他的請求已經得到處理，或者將在設定的時間段內得到處理 幾條建議 如果無法處理某個異常...
Scrum 指導原則
雖然這篇文章討論了scrum中的一些常見指導原則，但重要的是要記住這些指南是靈活的，應根據您團隊的需求進行塑造。當我提到規則時，我指的是那些無法修補以適應特定背景的方面。例如，沒有產品負責人，開發團隊和scrum master，您就無法做scrum。當我提到指南時，我指的是那些可能被改變以適應特定背...
Scrum 指導原則
雖然這篇文章討論了scrum中的一些常見指導原則，但重要的是要記住這些指南是靈活的，應根據您團隊的需求進行塑造。當我提到規則時，我指的是那些無法修補以適應特定背景的方面。例如，沒有產品負責人，開發團隊和scrum master，您就無法做scrum。當我提到指南時，我指的是那些可能被改變以適應特定背...