擲回例外狀況
當成員無法成功執行所應該執行的工作時，會擲回例外狀況；這樣的情況稱為執行失敗。例如，如果 Connect 方法無法連接到指定的遠端端點，則會發生執行失敗，並擲回例外狀況。
下列方針可讓您確保在適當時機擲回例外狀況。
請勿傳回錯誤碼；例外狀況是報告架構內錯誤的主要方法。
例外狀況的設計方針將討論您在使用例外狀況當中可獲得的許多好處。
要藉由擲回例外狀況來報告執行失敗；如果成員無法成功執行所應該執行的工作，這樣就應該視為執行失敗，且應該擲回例外狀況。
如果程式碼遇到的狀況是繼續執行下去會不安全時，請考慮呼叫 System.Environment.FailFast(System.String) (.NET Framework 2.0 版的一個功能) 來結束此處理序，而不要擲回例外狀況。
盡可能不要對一般的控制流程使用例外狀況，但是在可能發生競爭情形的系統失敗和作業中除外，架構設計人員應該設計 API，讓使用者可以編寫不會擲回例外狀況的程式碼。例如，您可以先提供一個方法來檢查先前的條件之後，再呼叫成員，讓使用者可以編寫不會擲回例外狀況的程式碼。
下列程式碼範例將示範如何進行測試，以避免在訊息字串為 null (Visual Basic 中為 Nothing) 時，擲回例外狀況。
public class Doer
{
// Method that can potential throw exceptions often.
public static void ProcessMessage(string message)
{
if (message == null)
{
throw new ArgumentNullException("message");
}
}
// Other methods...
}
public class Tester
{
public static void TesterDoer(ICollection<string> messages)
{
foreach (string message in messages)
{
// Test to ensure that the call
// won't cause the exception.
if (message != null)
{
Doer.ProcessMessage(message);
}
}
}
}
如需可以減少例外狀況擲回次數的設計模式之詳細資訊，請參閱例外狀況和效能。
請考量擲回例外狀況所帶來的效能含意。
要記錄因為成員合約的違規 (而非系統失敗)，而由可呼叫的公用成員所擲回的所有例外狀況，並將之視為合約的一部分。屬於合約一部分的例外狀況，不應該因為版本的不同而有所更動。
不要擁有可以根據某個選項而擲回或不擲回例外狀況的公用成員。
例如，請不要依照下列方式來定義成員：
Uri ParseUri(string uriValue, bool throwOnError)
不要擁有將例外狀況傳回為傳回值或 out 參數的公用成員。
這個方針僅適用於公開可見的成員，使用私用 Helper 方法來建構及初始化例外狀況，是可以接受的作法。
請考慮使用例外狀況產生器方法，從不同地方擲回相同例外狀況，是很常見的情形。為了避免程式碼過度膨脹，請使用可建立例外狀況及初始化其屬性的 Helper 方法。
Helper 方法不能擲回例外狀況，否則堆疊追蹤將不會正確反映造成例外狀況的呼叫堆疊。
不要從例外狀況篩選條件區塊中擲回例外狀況。當例外狀況篩選條件引發例外狀況時，Common Language Runtime (CLR) 會攔截此例外狀況，而篩選條件會傳回 false。這個行為難以從篩選條件的執行及明確傳回 false 來加以辨別，所以會很難偵錯。
類似 C# 的某些語言不支援例外狀況篩選條件。
避免從 finally 區塊明確擲回例外狀況；可以接受由擲回的呼叫方法產生的隱含擲回的例外狀況。
Portions Copyright 2005 Microsoft Corporation.All rights reserved.
Portions Copyright Addison-Wesley Corporation.All rights reserved.
如需設計方針的詳細資訊，請參閱由 Krzysztof Cwalina 和 Brad Abrams 所著，並由 Addison-Wesley 於 2005 年發行的「Framework 設計方針：可重複使用之 .NET 程式庫的慣例、慣用語法和模式」一書。