Web服務中的例外

Question

我的團隊正在開發一個基於服務（.NET WCF）的應用程序，我們正在嘗試確定如何處理內部服務中的異常。我們應該拋出異常嗎？返回序列化爲XML的異常？只需返回一個錯誤代碼？

請記住，用戶永遠不會看到這些例外情況，它僅適用於應用程序的其他部分。

Answer 1

WCF使用SoapFaults作爲從服務到客戶端或從客戶端到服務的異常傳輸方式。

您可以在合同接口使用FaultContract屬性聲明自定義SOAP錯誤：

例如：

[ServiceContract(Namespace="foobar")] 
interface IContract 
{ 
    [OperationContract] 
    [FaultContract(typeof(CustomFault))] 
    void DoSomething(); 
} 


[DataContract(Namespace="Foobar")] 
class CustomFault 
{ 
    [DataMember] 
    public string error; 

    public CustomFault(string err) 
    { 
     error = err; 
    } 
} 

class myService : IContract 
{ 
    public void DoSomething() 
    { 
     throw new FaultException<CustomFault>(new CustomFault("Custom Exception!")); 
    } 
} 

Answer 2

我有點困惑，我不是輕浮 - 你說你想返回序列化爲XML的異常，另一方面用戶永遠不會看到異常。誰會看到這些例外情況？

通常我會說使用WCF故障契約。

Answer 3

那麼，爲什麼不只是拋出標準的SOAPExceptions？錯誤代碼和序列化XML的問題在於它們都需要額外的邏輯來識別實際發生的錯誤。這種方法僅在您需要在Web服務的另一端進行專門的日誌記錄或邏輯時纔有用。這樣一個例子會返回一個標誌，表示「可以繼續」並顯示錯誤異常報告。

無論你如何拋出它，它都不會讓工作變得更容易，因爲主叫方仍需要認識到存在異常並處理它。

Answer 4

Phil，應用程序的不同部分使用WCF相互調用。通過「返回異常序列化爲XML」，我的意思是函數的返回值將是一個異常對象。成功將由null表示。

我不認爲這是正確的選擇。

WCF故障合同聽起來不錯，但我對他們一無所知。現在檢查谷歌。

Answer 5

我會避免發送異常直接返回給客戶端，除非你是好與很多細節被送回。

我會建議使用WCF錯誤來傳輸錯誤消息和代碼（可以用來決定接收方重試，出錯等），具體取決於錯誤發送方還是接收方。

這可以使用FaultCode.CreateReceiverFaultCode和FaultCode.CreateSenderFaultCode來完成。

我正在通過此權利的過程中，但遇到了一個討厭的障礙，似乎在WCF故障生成的SOAP 1.1響應。如果你有興趣，你可以看看我的問題在這裏：

.NET WCF faults generating incorrect SOAP 1.1 faultcode values