より効率的なものは何ですか？例外をスローするか、障害をスローする...私が見る限り、2つのシナリオがあります。
例外が発生してキャッチされました。既存のものをスローしますか、それともException新しいものを作成してFaultExceptionスローしますか？
独自のロジック（ユーザー名を空白にすることはできません）は、ExceptionまたはFaultExceptionとしてエラーをスローする必要があります。どちらを選びますか？
基本的に、ベストプラクティスの方法はどちらですか？WCFのボクシングまたはアンボクシングの例外についてどこかで読んだことを覚えているので、追加のリソースなどが必要になるので、質問します。それで、どちらがより効率的な方法だと思いますか？
WSDLコントラクトの観点から、各操作は最大で1つの応答を持つことができます。ただし、複数の障害コントラクトを定義できます。これにより、基本的に、クライアントに「、によって定義された応答、またはまたはによって定義された障害応答のいずれかを期待する」と通知さDataContractXれます。FaultContractYFaultContractZ
FaultExceptionsを使用すると、WSDLの表現方法をより細かく制御できます（または、定義済みのWSDLに対して準拠したサービスを作成する場合）。
本当に相互運用性を実現しようとしていて、これを実現するためにwsdlとsoapを完全に活用している場合は、FaultExceptionsを使用する必要があります。例外または障害例外を使用できる.NETのみの対話でWCFを使用している場合、パフォーマンスの違いは重要ではないと思います（ネットワークを介した通信は、例外を汎用にラップするWCFランタイムよりも桁違いに重要です）回線を介した伝送の障害）。
例外をどこでどのように処理するかによって異なります。クライアント（プラットフォームに関係なく）は、サービスコードが未処理の例外を許可するか、サービスが明示的にFaultExceptionをスローするか、FaultExceptionの汎用バージョンをスローするかにかかわらず、常にsoapフォールト例外を受け取ります。
特定のサービス条件を簡単に識別できるようにカスタム障害例外を定義するかどうかは、設計上の問題です。私の経験則では、クライアントがそのカスタムフォールトによってトリガーされる代替ロジックを実行することを期待している場合にのみ、カスタムフォールトをスローします。詳細な検証ロジックのすべてがカスタム障害によって駆動されることを本当に望まないため、検証のようなものは灰色の領域です。私は通常、単一のカスタム検証に失敗した障害を作成し、カスタム障害のリストプロパティとして検出できるすべての検証の問題を含めます。
例外の処理は常にコストのかかるプロセスですが、FaultExceptionをスローすることとサービス側で他の.NET例外をスローすることの間に実際のパフォーマンスの違いはありません。
私の理解では、wsHttpBindingを使用していて、FaultExceptionではなく.Net例外をスローした場合、Server-Clientチャネルは障害状態になり、既存のプロキシオブジェクトが使用できなくなるため、プロキシクラスオブジェクトを再作成する必要があります。したがって、ベストプラクティスはFaultExceptionを使用することかもしれません。
'Exception'を使用して単に例外をスローすると、WCFサービスはFaultExceptioninを背後で発生させ
<serviceDebug includeExceptionDetailInFaults="true"/>、web.configで言及しない限り、例外の根本原因がクライアントに認識されることはありません。クライアントに例外の背後にある理由/カスタムメッセージを知らせたい場合は、FaultExceptionを優先します。厳密に型指定された例外を設定することをお勧めします。