問題タブ [faultexception]

障害例外が境界を越えてスローされると、タイプパラメータを取り、WCF境界を越えて詳細オブジェクトを渡すことができます。ただし、障害例外が2つの境界を越えると（再スローされるため、または例外がスタックをバブルアップするため）、詳細オブジェクトが失われることに気付きました。これは仕様によるものですか？もしそうなら、なぜですか？

私が話していることを確認したい場合は、これが実際に動作していることを示すコードリポジトリがあります。

https://bitbucket.org/mckaysalisbury/doublefault/src/

TDetail から派生した例外の FaultException をキャッチするにはどうすればよいですか?
試してみcatch( FaultException<Exception> ) {}ましたが、うまくいかないようです。

編集
目的は、Detail プロパティにアクセスすることです。

解決：

少しトレースすると、例外Tが正しくシリアル化されないという問題があったため、CommunicationExceptionがスローされていたことがわかりました。なぜなら、2層の深さで、匿名で型付けされたオブジェクトがあり、それはシリアル化できなかったからです。それを削除し、変更をバブリングすると、修正されたように見えます。その前に私がやったことは他にもありましたが、それが何であったかを一生思い出せません。それは設定で行われなかったということだけです。

トレースから次のようなメッセージを受け取っていました。

元の投稿

今日、私は答えを見つけることができないという一見奇妙な問題に遭遇しました！

問題：FaultExceptionをスローすると、サービスがCommunicationExceptionをスローします。例外をスローしない限り、これは行われません。

私のサービスでは、障害契約を適切に定義しています。

次に、エラー状態で、正しいタイプの例外をスローします。

そして、私はクライアント側でそれをキャッチしています：

それはすべて私には問題ないように思えます、そしてそれがうまくいくはずです。ただし、エラー句をテストする（フィールドの欠落などの不正なデータを提供する）とすぐに、すべてが死んでしまいます。FaultExceptionをスローすると、代わりにサービスはメッセージとともにCommunicationExceptionをスローします

誰かがこれについていくつかの洞察を提供できますか？basicHttpバインディングを使用しており、wsHttpでも試しました。リクエストに応じて設定ファイルを投稿します。

私はこれについて読むためにそこにあるすべてを読みました、しかし多分私は何かを逃しています（まあ、確かに私は何かを逃しています、さもなければそれはすでに働いているでしょう）

サーバービジネスレイヤー内でいくつかの例外エラーをスローしています：

これはサービスでは未処理のままですが、IErrorHandlerキャッチして作成する必要がありますFaultMessage：

尋ねる必要はありません。デバッガーでパーツif (error is RfcException)部分に入るのを確認しました。そのコードをステップスルーして、問題なく最後まで到達しました。そのerrorHandlerはメッセージをラップしFaultException<RfcServiceFault>ます、RfcServiceFaultメッセージはこれです

このサービスには、faultContractを含むwcfサービスに必要なすべてのアノテーションがあります。

今：クライアントでのテスト、次のような簡単なテスト：

私はこの同様の問題に関する多くの投稿を読みました：

• FaultExceptionを処理できません
• 一般的なFaultExceptionをスローします
• c＃WCFは、基本タイプの障害例外をキャッチします
• WCF：WSDLファーストのアプローチ：障害タイプの生成に関する問題

しかし、これまでのところ何も役に立たないようです。web.configでWCFトレースを設定してみました。

そこにsvclogファイルを取得し、WCFトレースビューアーで開きますが、一連のメッセージのみが表示され、黄色のメッセージは例外を示しますが、クライアントがすでに表示しているもの、つまり受信されているものを確認するだけSystem.ServiceModel.FaultExceptionであり、一般的なもの

これを理解する方法はありますか？

編集は言及するのを忘れました、私はこのように設定で私のエラーハンドラを有効にしました：

WCF サービスを使用しているクライアントで作業しています。さまざまなケースで、サービスは、特定の障害の背後にある理由を通知する関連メッセージとともに FaultException を発生させるだけです。

これらの障害の一部は、クライアント アプリケーションで処理できるものですが、FaultExceptions Message または Reason で文字列の照合を実行して、対応できるものかどうかを判断するのはためらいがあります。

FaultException の FaultCode を使用して、処理できる特定の種類の Fault を識別できることを期待していましたが、これは純粋に少数の SOAP 障害を識別するためのもののようです。これについての私の解釈が間違っている場合は、訂正してください。

FaultException が発生する可能性があることはわかっていますが、障害の背後にある理由ごとに新しい型を作成する必要があると期待するのは非現実的だと感じています。

この状況をどのように処理しますか。わざとらしい例として。次のメソッドを提供するサービスを考えてみましょう。

上記の例で、存在しない ID で GetRecordById を呼び出すと、「レコードが見つかりません」というメッセージとともに FaultException を受け取ります。同様に、既に存在するレコードに対して Add を呼び出すか、存在しないレコードに対して Update を呼び出すと、失敗の理由を詳述する Message/Reason を含む FaultException が返されます。更新または挿入する必要があるかどうかを判断するには、レコードが存在するかどうかを知る必要があります。前述したように、文字列が同じままかどうかを制御できないため、単純に文字列を照合することをためらっています。

この状況 (RecordNotFoundException などを詳述する FaultException に関連付けられた型) またはエラーに関連する特定の詳細を定義する FaultException に関連付けられたジェネリック型で何を期待しますか。たとえば、メンバー Code (失敗の理由の定数または列挙識別子) を持つ RecordOperationExcpetion クラスと、ユーザー フレンドリなメッセージ。

少なくともこの方法で、文字列の一致に頼ることなくエラーの原因を特定できました。

あなたの考えは大歓迎です。

カスタム UserNamePasswordValidator を備えた WCF サーバーがあります。

クライアント側で、間違った認証情報をプロキシに追加して関数を呼び出します

サーバーのデバッガーで、FaultException がスローされていることがわかります。ただし、クライアントがこの例外を受け取ることはありません。クライアント側で TimeoutException になります。

正しい資格情報を使用すると、サーバー側の関数が呼び出され、すべてが正常に機能するため、wcf は正しく機能します。

しかし、クライアント側で資格情報が間違っていることを認識できるように、FaultException がクライアントにスローされるようにするには、どうすればよいでしょうか?

更新: WSHttpBinding を使用すると、MessageSecurityException をキャッチできます。しかし、WSDualHttpBinding とデュアル チャネルを使用していると、タイムアウトが発生します。

ReceiverのFaultCodeをスローしていますが、クライアントは応答の障害コードとして「s：Server」を返しています。「s：Receiver」の応答を取得するにはどうすればよいですか？

私のコード：

応答：

C＃での私のWCFサービスは次のようになります。

メソッドから返されるDTOは次のようになります。

私が見つけた典型的な例は、メソッド内からFaultExceptionをスローすることを示しています。しかし、私の場合、私のメソッドはエラーになりません。このエラーは、オブジェクトがクライアント/コンシューマーに返されるときに発生します。つまり、DataMember /PropertyXmlRepがシリアル化されているとき。

したがって、throwFaultExceptionをメソッド内に配置することはできません。ただし、「基になる接続が閉じられました。接続が予期せず閉じられました」というメッセージが表示されないようにします。ゲッター内で発生する適切なエラーをスローします。

MyDTOのゲッター内にtry/catchを入れようとはしていません。また、DTOをできるだけ単純にし、FaultExceptionsやWCFについて何も知らないようにしたいからです。他のアイデアはありますか？

編集：明確にするために、MyDtoDataContractのゲッターでエラーが発生していることを知っています。しかし、ゲッターの内部は危険な場所のように見えるので、他にどこでFaultExceptionをスローしますか？

編集＃2：以下のTimが提案するように、サービス側にキャッチオールエラーハンドラーを実装しました（IErrorHandlerを使用）。これは私の特定のケースでは機能しません。これは、エラーがOperationContract ReturnMyDTOMethod（）内では発生せず、シリアル化されているときにMyDto内で発生するためだと思います。言い換えると、馬がボルトで固定されているように見え（メソッドは正常に戻ります）、IErrorHandlerが使用できるようになるのは遅れています。具体的には、ProvideFault（）は起動しませんが、HandleError（）は起動します。その結果、まだチャネルが壊れているというメッセージが表示されます。これには、図面に戻る必要があります。つまり、MyDtoがエラーの生成などの特別なことを行わないようにします。

IIS で実行されているがファクトリを介して実行されている Web サービスは、スローされた元の例外を維持しません。

例えば：

私の Web サービスは、次のように FaultContractAttribute でマークアップされています。

私の Web サービスの実装は、次のようにカスタム例外をスローします。

それで：

1. 私の WCF - ファクトリを使用していない - が に似ている<%@ ServiceHost Language="C#" Debug="true" Service="MyService" %>場合、クライアント側で元の例外 (MyCustomException) を取得できます。

2. 私の WCF - USING some factory - が に似ている場合<%@ ServiceHost Language="C#" Debug="true" Service="MyService" Factory="MyFactory" %>、クライアント側では元の例外 (MyCustomException) を取得できず、SOAP 例外 (FaultException) のみを取得し、役に立たない一般的なトレースとメッセージを表示します

ノート：

WCF ファクトリ MyFactory は、その SERVICE HOST で実装され、IErrorHandler から開始された SERVICE BEHAVIOR が含まれています

このサービス動作では、ProvideFault メソッドは何もしません (この方法で元の例外を維持する方法がわかりません)。

要約すると、期待からの回答を求めます: WCF ファクトリを使用しているときに元の例外 (MyCustomException) を維持するにはどうすればよいですか? ありがとう。

そのため、WCF サービスで Enterprise Library を使用して、例外関連の作業をいくつか実行しようとしています。

私の考えは、「NullReferenceException」などの「カスタム例外ハンドラー」を設定し、「カスタム例外ハンドラー」で FaultException 例外を作成することです。

私の理解では、この「新しい」例外はネットワークを通過し、クライアントでキャッチします。

理解を深めるためのコード:

WCF サービス:

カスタム例外ハンドラ: (エンタープライズ ライブラリ)

NullReferenceException を「カスタム例外ハンドラー」にマップするアプリ構成ファイル:

そして最後に、この FaultException をキャッチすることを期待するクライアント コード:

しかし、代わりに、応答アクションが必要であることを示す ProtocolException が発生します。

アクション '' の操作 'メソッド' に対する応答メッセージを受信しました。ただし、クライアント コードにはアクション 'http://tempuri.org/MyService/MethodResponse' が必要です。

私は何を間違っていますか？「カスタム例外ハンドラー」でカスタム FaultContract を使用して FaultException を返す (明示的にスローしない) ことは可能ですか?

アドバイスをいただければ幸いです。

更新: ご覧のとおり、「カスタム例外ハンドラー」の処理後のアクションは「ThrowNewException」に設定されています。「NotifyRethrow」に変更すると、「ProtocolException」が発生しなくなります。代わりに、クライアントは通常の "FaultException" (カスタム型ではない) をキャッチします。

ここで問題となるのは、元のカスタム型の FaultException がネットワークを通過しない理由です。

Update 2 忘れていたことの 1 つは、WCF サービスが IIS ではなく ServiceHost 内で実行されていることです。したがって、基本的には、ServiceHost を作成し、この ServiceHost を介して Service1 インターフェイスを公開する Windows サービスがあります。

これがこの問題と関係があると私が考える理由は、Enterprise Library が、サービス境界内だけでなく、アプリケーション全体で例外を処理すると主張しているためです。これにより、例外のスローが遅すぎる可能性がありますか? それとも適切なレベルではありませんか？

更新 3
投稿ありがとうございます。そうです、私がカスタム ハンドラーをいじっている唯一の理由は、MyFaultCode 値を設定したいからです。私はあなたのアドバイスを試しました-2つのハンドラーを構成しました。

最初はカスタム ハンドラーで、NullReference 例外をキャッチします。次に、MyFaultContract フィールドを使用して、新しい例外 - MyApplicationException をスローします。

次に、2 番目のハンドラーを構成しました。組み込みの "Fault Contract Exception Handler" は、MyApplicationException をキャッチし、新しい FaultException を作成し、MyFaultcontract を MyApplicationException から新しく作成された FaultException に自動的にマップします。

WCF クライアントは、カスタム コントラクトではなく、一般的な FaultException を引き続きキャッチします。