「サービス参照の追加...」を使用して、Visual Studio 2010 に Web サービスを追加しました。これにより、 というファイルにコードが生成されますReference.cs。ここで、メソッドの 1 つを呼び出した場合、そのメソッドがスローする可能性のある例外を知りたくありません。SocketExceptionおそらく、またはIOException?などのネットワーク関連の例外をスローできます。
.NET の通常のメソッドは、msdn またはソース コード内でチェックして、スローされる可能性のある例外 ( File.Open など) を明らかにすることができます。ここで、後の段階でエラー メッセージを表示するために、キャッチして再スローする必要がある例外は明らかです。
これらの生成されたメソッドについて、それらがスローする可能性のある例外をどのように知ることができますか?
この場合、「標準」例外と「カスタム」例外 (FaultContactサービス開発者によって として定義され、サービス コントラクト リファレンスに存在するもの) があります。
最初のケースでは、あなたの懸念は、CommunicationExceptionとTimeoutException;であると思います。これらは、 (モデルのベースICommunicationObject.BeginOpen)の およびその他の「開く」方法の可能な例外を文書化しています。「終了」メソッドについて文書化されています。などのメッセージを送信するメソッド用もあります。可能性のあるより多くのものの中で、これらは発見可能でなければなりません。ICommunicationObjectCommunicationObjectFaultedExceptionQuotaExceededExceptionIRequestChannel.Request
上記にリンクされているMSDNの記事から、注目に値するのは次のとおりです。
System.TimeoutExceptionチャネルによってスローされるすべての例外は、 、System.ServiceModel.CommunicationException、または CommunicationException から派生した型のいずれかである必要があります 。(ObjectDisposedException などの例外もスローされる場合がありますが、呼び出し元のコードがチャネルを誤用したことを示すためだけです。チャネルが正しく使用されている場合は、指定された例外のみをスローする必要があります。)
次に、「障害」があります。これは、サービス側で発生した例外であり、(有効になっている可能性があります) 呼び出し元に詳細が示されます。呼び出し元はそれを処理するか、適切なクライアント側例外をスローできます。
障害を生成するとき、カスタム チャネルは障害を直接送信するのではなく、例外をスローし、その例外を障害に変換するかどうか、および送信方法を上のレイヤーに決定させる必要があります。
チャネルは、サブスクライブして、そのような状態に達したときに通知を受け、おそらく行動できるStateイベントを提供します。Faultedデフォルトでは (抑制 (?) を構成しない場合)、フォールトはマネージド例外として発生します。繰り返しますが、
WCF クライアントでは、クライアント アプリケーションにとって重要な通信中に発生する SOAP エラーは、マネージ例外として発生します。プログラムの実行中には多くの例外が発生する可能性がありますが、WCF クライアント プログラミング モデルを使用するアプリケーションは、通信の結果として [...] 2 つのタイプの例外を処理することを期待できます。
そして、これは上記のとを再び指します。CommunicationExceptionTimeoutException
最後に、少なくとも今のところは、予想外です。
FaultException予期されていない、または操作コントラクトで指定されていないエラーをリスナーが受信すると、例外がスローされます。通常、これは、アプリケーションがデバッグされていて、サービスのSystem.ServiceModel.Description.ServiceDebugBehavior.IncludeExceptionDetailInFaultsプロパティが true に設定されている場合に発生します。