Web サービスの例外

StackOverflow https://stackoverflow.com/questions/40122

質問

私のグループはサービスベース (.NET WCF) アプリケーションを開発しており、内部サービスで例外を処理する方法を決定しようとしています。例外をスローすべきでしょうか?XML としてシリアル化された例外を返しますか?エラーコードを返すだけですか?

これらの例外はユーザーには決して表示されず、アプリケーションの他の部分でのみ発生することに注意してください。

役に立ちましたか？

解決

WCF は使用します SoapFaults サービスからクライアントへ、またはクライアントからサービスへ例外を送信するネイティブな方法として。

カスタム SOAP フォールトを宣言するには、 FaultContract コントラクトインターフェイスの属性:

例えば：

[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!"));
    }
}

他のヒント

では、なぜ標準の SOAPExceptions をスローしないのでしょうか?エラー コードとシリアル化された XML の問題は、どちらも実際にエラーが発生したことを認識するために追加のロジックが必要であることです。このようなアプローチは、Web サービスの反対側で実行する必要がある特殊なロギングまたはロジックがある場合にのみ役立ちます。そのような例は、エラー例外レポートで「続行しても問題ありません」というフラグを返すことです。

どのようにスローするかに関係なく、呼び出し側は例外があったことを認識してそれに対処する必要があるため、作業が簡単になるわけではありません。

私は少し混乱していますが、軽薄なわけではありません。XML としてシリアル化された例外を返したい一方で、ユーザーには例外が表示されないと言われています。誰がこれらの例外を確認するのでしょうか?

通常は、WCF フォールト コントラクトを使用すると思います。

フィル、アプリケーションのさまざまな部分が WCF を使用して相互に呼び出します。「XML としてシリアル化された例外を返す」とは、関数の戻り値が例外オブジェクトになることを意味しました。成功は null で示されます。

それは正しい選択肢ではないと思います。

WCF 障害コントラクトは良さそうですが、それについては何も知りません。今グーグルをチェックしています。

それほど詳細な情報が返されても問題ない場合を除き、例外をクライアントに直接送信することは避けたいと思います。

送信者または受信者に障害があるかどうかに応じて、WCF 障害を使用してエラー メッセージとコード (受信者が再試行するか、エラーアウトするかなどを決定するために使用できるもの) を送信することをお勧めします。

これは、FaultCode.CreateReceiverFaultCode および FaultCode.CreateSenderFaultCode を使用して実行できます。

私は現在これを検討しているところですが、WCF 障害で生成された SOAP 1.1 応答にあると思われる厄介な問題に遭遇しました。興味があれば、それに関する私の質問をここで確認してください。

.NET WCF エラーにより不正な SOAP 1.1 フォールトコード値が生成される

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top