來自微軟關於異常處理的17條軍規

2022-02-26 18:58:37 字數 2652 閱讀 7518

1. 不要返回錯誤**。異常是報告框架中的錯誤的主要手段。

這個就不討論了,異常包含的資訊量遠不是幾個錯誤**可以替代的.

2. 通過引發異常來報告執行故障。如果某一成員無法按預期方式成功執行,則應將這種情況視為乙個執行故障並引發乙個異常。

例如函式的引數檢測,引數不符合輸入要求,就應該引發乙個異常.另外還有很多情況,只要程式無法按照預定的邏輯執行下去,就應該引發乙個異常.

3.如果**遇到繼續執行則不安全的情況,應考慮通過呼叫 system.environment.failfast(system.string)(.net framework 2.0 中的一種功能)來終止程序,而不是引發異常。4. 盡可能不對正常控制流使用異常。

就是不能用異常來控制業務邏輯.異常是不應該屬於正常運作範圍.你的程式catch部分除了寫日誌,釋放資源(更多時候應該放到finally塊)和丟擲異常外,不應該有任何業務邏輯.

5. 考慮引發異常的效能影響.

異常是極其消耗資源的,當大量引發異常的時候會導致效能問題.所以,結合上一條,不要用異常控制流程.就是你的**正常使用下,是不需要觸發異常的.

6. 不要包含可以根據某一選項引發或不引發異常的公共成員。

就是不要建立類似function(bool isthrowexception)這樣的函式或方法,結合第3條理解,這樣的方法已經觸犯了用異常控制流程的禁忌.觸發異常必須丟擲,一直拋到你處理異常的地方.

7. 不要包含將異常作為返回值或輸出引數返回的公共成員。

同理,觸犯第3條軍規.

9. 避免從 finally 塊中顯式引發異常。可以接受因呼叫引發異常的方法而隱式引發的異常。

finally模組是處理異常的地方,不應該在這個地方引發異常.但是如果要呼叫引發異常的方法做處理而引發的異常則可以接受。

10. 考慮引發 system 命名空間中的現有異常,而不是建立自定義異常型別。如果錯誤狀態可以通過不同於現有任何其他異常的方法以程式設計方式進行處理,則要建立並引發自定義異常。否則,引發乙個現有異常。

盡量引發系統異常,除非必要不必建立自定義異常類。只要日誌寫得好,處理異常會很方便。

11. 引發適當的最具體(派生程度最大)的異常。

就是盡量讓異常靠近實際錯誤情況。而不是一律丟擲systemexception了事。

12.不要引發 system.exception 或 system.systemexception。

因為引發最普遍的異常並不能更有效的幫助人們認清楚錯誤和及時進行錯誤處理。exception越具體,幫助越大。

13. 避免捕捉 system.exception 或 system.systemexception,在頂級異常處理程式中除外。

除非在頂級最終寫log的時候,否則不應該捕捉最普遍的異常。個人因為只應該在頂級處理捕捉異常。底層異常一律往上拋即可。

14. 對於可能在常見方案中引發異常的成員,可以考慮使用 tester-doer 模式來避免與異常相關的效能問題。

例如,對於函式的引數問題,就必須建立檢測類檢測輸入是否正確.

對於可能在常見方案中引發異常的成員,可以考慮使用 tryparse 模式來避免與異常相關的效能問題。

tryparse模式參考int.tryparse等.就是建立正常執行的條件避免丟擲異常.

15. 一般不要隱藏異常轉而丟擲其他異常。

不要將丟擲的異常攔截轉而拋出自定義的異常。除非丟擲的異常而包含該原始異常,否則對異常了解非常不利。

16. 定要在所有異常上都提供(至少是這樣)下列常見建構函式。確保引數的名稱和型別與在下面的**示例中使用的那些相同。

code

public

class

newexception : baseexception, iserializable

public

newexception(

string

message)

public

newexception(

string

message, exception inner)

//this constructor is needed for serialization.

protected

newexception(serializationinfo info, streamingcontext context)

}17.在引發異常時為開發人員提供豐富且有意義的訊息文字。

"訊息應說明導致異常的原因並清楚描述避免該異常需採取的操作。訊息應針對開發人員設計。確保異常訊息的語法正確。頂級異常處理程式可以向應用程式終端使用者顯示異常訊息。確保訊息文字的每個句子都是以句號(「。」)結尾。這樣,向使用者顯示異常訊息的**不必處理開發人員忘記最後面的句號的情況,這種處理相當麻煩而且代價很大。避免在異常訊息中使用問號(「?」)和感嘆號(「!」)。不要在不要求相應許可權的異常訊息中透露安全敏感資訊。"

有效使用記憶體的 6 條技巧 來自微軟官網

本頁內容 有效布局資料結構並盡可能重用它們。在啟動時將未分頁的池記憶體用於長期用途。經濟有效地使用記憶體 使用後備列表 避免頻繁地建立和取消虛擬位址空間的對映 測試與驗證 本文提供在 microsoft windows 家族作業系統核心模式驅動程式中有效使用記憶體的技巧。有效使用記憶體有助於提高驅動...

pandas 17 關於nan的處理

在pandas中有個另類的存在就是nan,解釋是 not a number,不是乙個數字,但是它的型別確是乙個float型別。numpy中也存在關於nan的方法,如 np.nan 對於pandas中nan的處理,簡單的說有以下幾個方法。檢視是否是nan,s1.isnull 和 s1.notnull ...

關於異常處理的筆記總結

一 異常處理 1.如果由於return continue break 等語句而使控制轉移到try 塊之外,在控制轉移到try 塊外面之前,仍然執行finally 塊中的內容。2.但在try 塊或catch 塊中如果執行了system.exit 方法,則終止虛擬機器,此時不會再執行finally 塊。...