什麼更有效？拋出異常或拋出一個錯誤......我看到它的方式是，有2種情況：發生WCF - 拋出異常或FaultException？
例外，並抓住了，你扔現有Exception或創建一個新的FaultException扔了嗎？
您自己的邏輯（例如用戶名不能爲空）需要拋出一個錯誤，作爲Exception或FaultException。你選擇哪一個？
基本上，哪種方式是最佳實踐方式？我問，因爲我記得閱讀關於WCF拳擊或拆箱異常的地方，它花費額外的資源和類似......所以我想也是，這是更有效的方式？
從WSDL Contract Perspective開始，每個操作最多隻能有一個響應。但是，您可以定義多個故障合同，這基本上告訴客戶「期望由DataContractX定義的響應或由FaultContractY或FaultContractZ定義的故障響應。」
使用FaultExceptions可以更好地控制WSDL的表示方式（或者根據已定義的WSDL編寫兼容的服務）。
如果您真的試圖實現互操作性並充分利用wsdl和soap來實現這一目標，則需要使用FaultExceptions。如果您使用WCF進行僅支持.NET的交互，您可以使用異常或故障異常，但我認爲性能差異不會很大（通過網絡進行通信的量級比WCF運行時將異常封裝到通用中更重要通過電線傳輸故障）。
它可以取決於你在哪裏以及如何處理異常。無論服務代碼是否允許未處理的異常，客戶端（不管平臺）總是會收到一個SOAP錯誤異常，該服務會顯式拋出FaultException或拋出FaultException的通用版本。
是否要定義自定義故障異常以便更容易識別特定的服務條件是一個設計問題。我的經驗法則是當我期望客戶端執行由定製錯誤觸發的替代邏輯時，僅拋出自定義錯誤。像驗證這樣的東西是一個灰色區域，因爲你真的不希望你所有的詳細驗證邏輯都是由定製故障驅動的。我通常會創建一個自定義驗證失敗的故障，並且它包含全部它可以找到的自定義故障列表屬性的驗證問題。
處理異常總是一個代價高昂的過程，但在服務端引發FaultException或任何其他.NET異常之間沒有真正的性能差異。
根據我的理解，如果您使用wsHttpBinding，並且如果您拋出.Net異常而不是FaultException，則服務器 - 客戶端通道將處於故障狀態，並且必須將該代理類對象重新創建爲現有代理對象將無法使用。所以最好的做法可能是使用FaultException。
如果你只是使用「例外」拋出一個異常，WCF服務將提高FaultExceptionin落後和異常的根本原因絕不會通過客戶端，除非你提到在web.config中 <serviceDebug includeExceptionDetailInFaults="true"/>是已知的。如果您希望客戶端知道異常背後的原因/定製消息，請選擇FaultException。具有類型分散的異常是最佳做法。