前緣
異常設計準則，參考微軟msdn，結合自己的理解和過去的開發中對異常錯誤的處理，總結下軟體開發架構，如何更好地設計一套異常錯誤準則。
介紹準則
execution failure概念
The meaning of execution failure: execution failure occurs whenever a member cannot do what it was designed to do (what the member name implies). For example, if the OpenFile method cannot return an opened file handle to the caller, it would be considered an execution failure.
##操作失敗的意思：無論何時一個成員模組不能完成它預期的任務時，就稱為發生了一次操作失敗。例如OpenFile方法不能給caller一個開啟檔案的句柄，這就是一個操作失敗。
架構中處理異常
In the Framework, exceptions are used for all error conditions, including execution errors.
#翻譯：
在框架中，異常被用來處理所有的錯誤條件，包括執行錯誤。
總結準則
哪些方法在設計異常時應該被禁止，哪些應該要without hesitation to do，哪些需要考慮，都列在下方的表格中。
編號
| 方法 | 做法 |
1
| 回傳錯誤代碼 |
禁止 |
|
#2
| 執行錯誤，要拋出例外；如OpenFile()未傳回檔案句柄 |
建議 |
|
#3
| 假如程式碼再繼續執行就變得不安全時，考慮是呼叫System.Environment.FailFast終止進程還是拋異常。 |
考慮 |
|
4
| 如果有可能的話，在正常的控制流處，拋異常，見下面的分析 |
禁止 |
|
5
| 拋異常對效能的影響。 |
考慮 |
|
6
| 協定中納入異常處理部分 |
建議 |
|
7
| 將異常作為回傳值傳回 |
禁止 |
|
#8
| 使用異常產生器方法，為避免程式碼膨脹, 用helper方法建立異常和屬性. |
考慮 |
|
#9
| 異常篩選器中拋出異常. |
禁止 |
|
10
| 從finally 區塊中顯示地拋出例外 |
禁止 |
|
對第4條做說明：
In daily coding, consider the Tester-Doer pattern for members that may throw exceptions in common scenarios to avoid perance problems related to exceptions. The Tester-Doer pattern pides a call that might throw exceptions into two parts: a Tester and a Doer. The Tester performs a test for the state that can cause the Doer to throw an exception . The test is inserted just before the code that throws the exception, thereby guarding against the exception. 來自//m.sbmmt.com/
參考的範例程式碼：
Tester和Doer各司其職，完美的減少了異常拋出，提升性能。
Doer：上面的狀態監控是好的，才能DoProcess()處理；如果是false，並且如果DoProcess()中包含DoCheck()邏輯，則會拋出異常，但是這樣分隔開後，DoProcess( )將不會拋出異常！
if(DoCheck()==true)//这是Tester:状态监测
DoProcess();登入後複製
軟體開發常見異常及處理方式（自行總結）
1 UI層暴露出的操作接口，建議包裹try{}catch{}塊，catch中將拋出的異常寫入到磁碟中。
2 UI層中用到計時器時，計數器的回呼函數出現異常後，要stop掉計時器，防止錯誤日誌一直寫入檔案。
3 底層建議不包裹try{}catch{}塊，建議用throw直接拋出異常，因為UI層上包裹了try{}和catch{}塊，所以沒必要寫在這些層。
4 throw會直接中斷以後操作，跳到所屬堆疊外層包裹try{}和catch{}，即UI層，利用這個性質，一般建議函數不要回傳錯誤碼。
5 處理批次匯入的資料時，局部出現異常。 Excel導入人員，設備，計劃，物料，工藝等，如果某一行資料違規了，這時候不建議拋出異常，因為一旦拋出異常，意味著後面行的資料導入不進來，並且已經導入進去的成為髒數據。
一般有兩種做法：某行出現違規數據，記錄到日誌文件中，日後根據這個文件查到那條數據未導入，然後單獨處理這一行即可；在導入前，直接檢查所有行的資料是否合法，檢查無誤後，再一一導入，否則直接彈出提示，任何資料都寫不到資料庫。 一般建議後者做法。這種做法稱為：Tester-Doer異常模式，也是微軟建議的做法。
6 處理看板展示數據，局部出現異常。這個處理模式跟5是有區別的，一般此時出現異常，往往採取5的前者做法：展示出正確的數據，違規的數據寫入到日誌中，留待查看；但是也有可能，如果展示的介面，主要的資料不存在，則直接拋出異常，寫入日誌，透過日誌解決。因此要根據資料的異常嚴重程度去處理。
7 根據開發文件、日誌，分析，盡量做到能夠找到某個功能未實現的原因。首先要保留好開發文檔，查看使用者現在的要求是不是和開發文檔中的一致。如果一致，此時日誌的作用就顯示出來了，例如，匯總一周內所有工序的完工餅狀圖，如果一條工序數據都沒有，那麼餅狀圖可能就沒有，在開發過程中，如果檢查了是不是存在工序，如果沒有找到一條工序，可能會拋出異常，然後寫入日誌地話，原因就會找到。因此這類問題，也要寫入日誌，儘管它不是錯誤，但可以歸為異常。
8 函數傳回一個對象，其方法和屬性被後續邏輯引用。這是不可避免的！並且大部分功能的實作都依賴於此。傳回的這個物件因為要被後續引用，所以建議做null比較，如果為null，是傳遞給UI層，彈出訊息提示，還是直接拋出異常，UI層處理後寫入日誌，視情況而定。
以上就是.net及其他架構中異常(Except) 設計準則的詳細介紹的內容，更多相關內容請關注PHP中文網（m.sbmmt.com）！
