【正文】 遞給成員，而成員方法不支持null實參，則拋出ArgumentNullException。如果實參值超出由調用方法定義的可接受范圍，則拋出 ArgumentOutOfRangeException異常。 事件254。 一定請 注意事件處理方法中可能會執(zhí)行任意代碼?？紤]將引發(fā)事件的代碼放入一個trycatch 塊中，以避免由事件處理方法中拋出的未處理異常引起的程序終止。 253。 一定不要 在有性能要求的API中使用事件。雖然事件易于理解和使用，但是就性能和內存消耗而言，它們不如虛函數。 成員方法重載254。 一定請 使用成員方法重載 ，而不是定義帶有默認參數的成員方法。默認參數并不是CLS兼容的，所以不能被某些語言重用。 同時，帶有默認參數的成員方法存在一個版本問題。我們考慮成員方法的版本1將可選參數默認設置為123。當編譯代碼調用該方法，且沒有指定可選參數時，編譯器在調用處直接將123嵌入代碼中?，F(xiàn)在，版本2將默認參數修改為863，如調用代碼沒有重新編譯，那么它會調用版本2的方法，并傳遞123作為其參數。（123是版本1的默認參數，而不是版本2的。）。Good: Public Overloads Sub Rotate（ByVal data As Matrix） Rotate（data, 180）End SubPublic Overloads Sub Rotate（ByVal data As Matrix, ByVal degrees As Integer） 39。 Do rotation hereEnd SubBad: Public Sub Rotate（ByVal data As Matrix, Optional ByVal degrees As Integer = 180） 39。 Do rotation hereEnd Sub253。 一定不要任意改動重載方法中的參數名 。如果一個重載函數中的參數代表著另一個重載函數中相同的參數，該參數則應該有相同的命名。具有相同命名的參數應該在重載函數中出現(xiàn)在同一位置。254。 一定請僅將最長重載函數設為虛函數 （為了拓展性考慮）。短重載函數應該一直調用到長重載函數。 接口成員253。 您不應該在沒有合理理由的情況下顯式的實現(xiàn)接口成員。顯式實現(xiàn)的成員可能使開發(fā)者感到困惑，因為他們不會出現(xiàn)在Public成員列表內，且會造成對值類型不必要的裝箱拆箱操作。254。 您應該在成員只通過接口來調用的情況下，顯式的實現(xiàn)成員接口。 虛成員方法相較于回調和事件，虛成員方法性能上有更好的表現(xiàn)。但是比非虛方法在性能上低一點。253。 一定不要在沒有合理理由的情況下，將成員方法設置為虛方法，您必須意識到相關設計，測試，維護虛方法帶來的成本。 254。 您應該 傾向于為虛成員方法設置為Protected的訪問性，而不是Public訪問性。 Public成員應該通過調用Protected的虛方法來提供拓展性（如果需要的話）。 靜態(tài)類254。 一定請 合理使用靜態(tài)類。靜態(tài)類應該被用于框架內基于對象的核心支持輔助類。 抽象類253。 一定不要 在抽象類中定義Public或ProtectedInternal的構造函數。254。 一定請 為抽象類定義一個Protected，或Internal構造函數。 Protected構造函數更常見，因為其允許當子類創(chuàng)建時，基類可以完成自己的初始化工作。 public abstract class Claim { protected Claim（） { ... }} internal 構造函數用于限制將抽象類的實現(xiàn)具化到定義該類的程序集。public abstract class Claim{ internal Claim（） { ... }} 命名空間254。 一定請 在一站式代碼示例庫中使用 Visual Studio 創(chuàng)建的項目的默認的命名空間。 錯誤和異常 拋出異常 254。 一定請 通過拋出異常來告知執(zhí)行失敗。 異常在框架內是告知錯誤的主要手段。如果一個成員方法不能成功的如預期般執(zhí)行，便應該認為是執(zhí)行失敗，并拋出一個異常。一定不要返回一個錯誤代碼。254。 一定請 拋出最明確，最有意義的異常（繼承體系最底層的） 。比如，如果傳遞了一個null實參，則拋出ArgumentNullException ，而不是其基類ArgumentException 。 拋出 。 253。 一定不要 將異常用于常規(guī)的控制流。除了系統(tǒng)故障 或者帶有潛在競爭條件的操作，您編寫的代碼都不應該拋出異常。比如，在調用可能失敗或拋出異常的方法前， 您可以檢查其前置條件，舉例，// C 示例:if （collection != null amp。amp。 !）{ （additionalNumber）。}253。 一定不要 從異常過濾器塊內拋出異常。當一個異常過濾器引發(fā)了一個異常時，該異常會被CLR捕獲，該過濾器返回false。該行為很難與過濾器顯式的執(zhí)行并返回錯誤區(qū)分開，所以會增加調試難度。39。 sample39。 This is bad design. The exception filter （When clause） 39。 may throw an exception when the InnerException property39。 returns nullTry ...Catch e As ArgumentException _When （File） ...End Try253。 一定不要顯式的從finally塊內拋出異常。從調用方法內隱式的拋出異常是可以接受的。 異常處理253。 您不應該 通過捕獲籠統(tǒng)的異常，，或者 .NET 代碼中其他異常，來隱藏錯誤。一定要捕獲代碼能夠處理的、明確的異常。您應該捕獲更加明確的異常，或者在Catch塊的最后一條語句處重新拋出該普通異常。以下情況隱藏錯誤是可以接受的，但是其發(fā)生幾率很低：Good: // C sample:try{ ...}catch（ exc）{ ...}catch（ exc）{ ...}catch（ exc）{ ...}Bad: // C sample:try{ ...}catch （Exception ex）{ ...}254。 一定請 在捕獲并重新拋出異常時，傾向使用throw 。這是保持異常調用棧的最佳途徑：Good: // C sample:try{ ... // Do some reading with the file}catch{ = position。 // Unwind on failure throw。 // Rethrow}Bad: // C sample:try{ ... // Do some reading with the file}catch （Exception ex）{ = position。 // Unwind on failure throw ex。 // Rethrow} 資源清理253。 一定不要 。 Tryfinally 塊254。 一定請 使用 tryfinally 塊來清理資源， trycatch 塊來處理錯誤恢復。 一定不要 使用 catch 塊來清理資源。一般來說，清理的邏輯是回滾資源 （特別是原生資源） 分配。舉例： // C sample:FileStream stream = null。try{ stream = new FileStream（...）。 ...}finally{ if （stream != null） （）。}為了清理實現(xiàn)了IDisposable 接口的對象，C 和 提供了using 語句來替代 tryfinally 塊。// C sample:using （FileStream stream = new FileStream（...））{ ...}許多語言特性都會自動的為您寫入tryfinally 塊。例如 C/VB的 using 語句， C的lock語句， VB的SyncLock 語句， C的foreach語句以及VB For Each 語句。 基礎Dispose 模式 接口，聲明實現(xiàn)了所有資源清理邏輯的 Dispose（bool） 方法，該方法被Dispose 方法和可選的終結器所共享。請注意，本章節(jié)并不討論如何編寫一個終結器?？山K結類型是該簡單模式的拓展，我們會在下個章節(jié)中討論。如下展示了基礎模式的簡單實現(xiàn)：// C sample:public class DisposableResourceHolder : IDisposable { private bool disposed = false。 private SafeHandle resource。 // Handle to a resource public DisposableResourceHolder（） { = ... // Allocates the native resource } public void DoSomething（） { if （disposed） throw new ObjectDisposedException（...）。 // Now call some native methods using the resource ... } public void Dispose（） { Dispose（true）。 （this）。 } protected virtual void Dispose（bool disposing） { // Protect from being called multiple times. if （disposed） return。 if （disposing） { // Clean up all managed resources. if （resource != null） （）。 } disposed = true。 }}254。 一定請為包含了可釋放類型的類型實現(xiàn)基礎Dispose 模式。 254。一定請 拓展基礎 Dispose 模式來提供一個 終結器。比如，為存儲非托管內存的緩沖實現(xiàn)該模式。254。 您應該 為即使類本身不包含非托管代碼或可清理對象，但是其子類可能帶有的類實現(xiàn)該基礎 Dispose 模式。 類。雖然它是一個不帶任何資源的抽象類 ，大多數子類卻帶有資源，所以應該為其實現(xiàn)該模式。 254。 一定請 聲明一個protected virtual void Dispose（bool disposing）方法來集中所有釋放非托管資源的邏輯。 所有資源清理都應該在該方法中完成。用終結器 和 方法來調用該方法。如果從終結器內調用，則其參數為 false 。它應該用于確保任何在終結中運行的代碼不應該被其他可終結對象訪問到。下一章節(jié)我們會詳細介紹終結器的細節(jié)。 // C sample:protected virtual void Dispose（bool disposing）{ if （disposing） { // Clean up all managed resources. if （resource != null） （）。 } }}254。一定請 通過簡單的調用Dispose（true），（this） 來實現(xiàn)IDisposable 接口。僅當Dispose（true） 成功執(zhí)行完后才能調用 SuppressFinalize 。// C sample:public void Dispose（）{ Dispose（true）。 （this）。}253。 一定不要 將無參Dispose 方法定義為虛函數 。 Dispose（bool） 方法應該被子類重寫。 253。 您不應該 從Dispose（bool） 內拋出異常，除非包含它的進程被破壞（內存泄露，不一致的共享狀態(tài)，等等）等極端條件。用戶不希望調用Dispose 會引發(fā)異常。比如，考慮在C代碼內手動寫入 tryfinally 塊:TextReader tr = new StreamReader（（））。try{ // Do some stuff}finally { （）。 // More stuff}如果Dispose 可能引發(fā)異常，那么finally塊的清理邏輯不會被執(zhí)行。為了解決這一點，用戶需要將所有對于Dispose （在它們的 finally 塊內!）的調用放入try 塊內，這