當服務遇到非預期的例外狀況或錯誤時，有多種方式可以設計例外狀況處理解決方案。 雖然沒有單一「正確」或「最佳做法」錯誤處理解決方案，但有多個有效的路徑可供考慮。 根據WCF實作的複雜度、例外狀況的類型和頻率、處理與未處理的例外狀況本質，以及任何相關聯的追蹤、記錄或原則需求，通常建議實作混合式解決方案，結合下列清單中的多個方法。
本節的其餘部分會更深入地說明這些解決方案。
Microsoft企業連結庫
Microsoft企業連結庫例外狀況處理應用程式區塊可協助實作常見的設計模式，並建立一致的策略來處理企業應用程式的所有架構層中發生的例外狀況。 其設計目的是支援應用程式元件中 catch 語句中包含的一般程式代碼。 例外狀況處理應用程式區塊可讓開發人員將此邏輯封裝為可重複使用的例外狀況處理程式，而不是在整個應用程式中重複此程式碼（例如記錄例外狀況資訊的程式代碼）。
此函式庫隨附現成可用的 Fault Contract 例外狀況處理器。 此例外狀況處理程序的設計目的是在 WCF 服務界限上使用，並從例外狀況產生新的錯誤合約。
應用程式區塊旨在納入常用的最佳做法，並提供整個應用程式例外狀況處理的常見方法。 另一方面，自行開發的自定義錯誤處理程式和錯誤合約也非常有用。 例如，自定義錯誤處理程式提供絕佳的機會，將所有例外狀況自動升階為 FaultExceptions，以及將記錄功能新增至您的應用程式。
如需詳細資訊，請參閱 Microsoft Enterprise Library。
處理預期的例外狀況
適當的動作是抓住每個作業或相關擴充點的預期例外狀況，決定是否可以從中復原，並在FaultException<T>中傳回適當的自定義錯誤。
使用 IErrorHandler 處理非預期的例外狀況
若要處理非預期的例外狀況，建議的方式是「掛勾」IErrorHandler。 錯誤處理程式只會攔截 WCF 運行時間層級的例外狀況（「服務模型」層），而不是在通道層。 在通道層級掛接 IErrorHandler 的唯一方法是建立自訂通道，但在多數情況下不建議這麼做。
「未預期的例外狀況」通常不是無法復原的例外狀況，也不是處理例外狀況;而是非預期的使用者例外狀況。 無法復原的例外狀況（例如記憶體不足例外狀況）–通常由 服務模型例外狀況處理程序 自動處理的例外狀況 ，通常無法正常處理，而且處理這類例外狀況的唯一原因可能是執行額外的記錄，或將標準例外狀況傳回給用戶端。 在處理訊息的過程中發生處理例外狀況，例如在序列化、編碼器或格式化器層級上，通常無法由 IErrorHandler 來處理，因為當這些例外狀況發生時，錯誤處理程式介入通常不是為時過早，就是為時已晚。 同樣地，無法在 IErrorHandler 處理傳輸例外狀況。
使用 IErrorHandler，您可以在擲回例外狀況時明確控制應用程式的行為。 您可以：
決定是否要將錯誤傳送至用戶端。
以錯誤取代例外狀況。
以另一個錯誤取代錯誤。
執行記錄或追蹤。
執行其他自定義活動。
您可以將它新增至服務的通道發送器的 ErrorHandlers 屬性，以安裝自定義錯誤處理程式。 可以有多個錯誤處理程式，而且會依新增至此集合的順序呼叫它們。
IErrorHandler.ProvideFault 會控制傳送至客戶端的錯誤訊息。 不論服務中作業擲回的例外狀況類型為何，都會呼叫這個方法。 如果這裡未執行任何作業，WCF 會假設其預設行為，並繼續執行，就像沒有自定義錯誤處理程式一樣。
您可能可以使用此方法的其中一種情況是當您想要在例外傳送至用戶端之前建立將例外轉換成故障的中央位置（確保實例未處置，且通道不會移至故障狀態）。
IErrorHandler.HandleError 方法通常用來實作錯誤相關行為，例如錯誤記錄、系統通知、關閉應用程式等。IErrorHandler.HandleError 可以在服務內的多個位置呼叫，並根據擲回錯誤的位置而定，HandleError 方法可能或可能不會由與作業相同的線程呼叫：在這方面沒有保證。
處理 WCF 外部的例外狀況
通常，組態例外狀況、資料庫連接字串例外狀況和其他類似的例外狀況可能會發生在WCF 應用程式的內容中，但本身不是服務模型或Web服務本身所造成的例外狀況。 這些例外狀況是 Web 服務外部的「一般」例外狀況，應該處理，就像處理環境中其他外部例外狀況一樣。
追蹤例外狀況
追蹤是唯一可以概括所有例外狀況的地方。 如需追蹤和記錄例外狀況的詳細資訊，請參閱追蹤和記錄。
使用 WebGetAttribute 和 WebInvokeAttribute 時的 URI 範本錯誤
WebGet 和 WebInvoke 屬性可讓您指定 URI 範本，將要求地址的元件對應至作業參數。 例如，URI 範本 「weather/{state}/{city}」 會將要求地址對應至常值令牌、名為 state 的參數，以及名為 city 的參數。 然後，這些參數可能會依名稱系結至作業的一些正式參數。
範本參數會以 URI 內的字串形式顯示，而具類型合約的正式參數可能是非字串類型。 因此，必須先進行轉換，才能叫用作業。 可用的 轉換格式表格 。
不過，如果轉換失敗，則無法讓作業知道發生錯誤。 型別轉換會以分派失敗的形式呈現。
您可以藉由安裝錯誤處理程式，來檢查類型轉換調度失敗，就如同檢查許多其他類型的調度失敗一樣。 呼叫 IErrorHandler 擴充點來處理服務層級例外狀況。 從該處，可能會選擇要傳回給呼叫者的回應，以及執行任何自定義工作和報告。