私のグループはサービス ベース (.NET WCF) アプリケーションを開発しており、内部サービスで例外を処理する方法を決定しようとしています。例外をスローする必要がありますか? XML としてシリアル化された例外を返しますか? エラーコードを返すだけですか?
ユーザーがこれらの例外を目にすることは決してないことに注意してください。これは、アプリケーションの他の部分のためだけのものです。
私のグループはサービス ベース (.NET WCF) アプリケーションを開発しており、内部サービスで例外を処理する方法を決定しようとしています。例外をスローする必要がありますか? XML としてシリアル化された例外を返しますか? エラーコードを返すだけですか?
ユーザーがこれらの例外を目にすることは決してないことに注意してください。これは、アプリケーションの他の部分のためだけのものです。
WCFはSoapFaults
、サービスからクライアント、またはクライアントからサービスのいずれかに例外を送信するネイティブな方法として使用します。
FaultContract
コントラクトインターフェイスの属性を使用して、カスタムSOAP障害を宣言できます。
例えば:
[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障害コントラクトを使用すると思います。
Phil、アプリケーションのさまざまな部分がWCFを使用して相互に呼び出します。「XMLとしてシリアル化された例外を返す」とは、関数の戻り値が例外オブジェクトであることを意味します。成功はnullで示されます。
私はそれが正しい選択肢だとは思いません。
WCFの障害契約は良さそうに聞こえますが、私はそれらについて何も知りません。今グーグルをチェックしています。
それほど多くの詳細が返送されても問題ない場合を除き、例外をクライアントに直接返送することは避けます。
WCF フォールトを使用してエラー メッセージとコード (受信者が再試行するか、エラーを出すかなどを決定するために使用できるもの) を送信することをお勧めします。
これは、FaultCode.CreateReceiverFaultCode および FaultCode.CreateSenderFaultCode を使用して実行できます。
私は今、これを行っているところですが、WCF 障害で生成された SOAP 1.1 応答のように思われる厄介な障害に遭遇しました。興味がある場合は、ここで私の質問をチェックしてください。