私のグループは、サービスベースの(.NET WCF)アプリケーションを開発しており、内部サービスの例外処理方法を決定しようとしています。私たちは例外を投げるべきですか?返される例外はXMLとしてシリアル化されますか?エラーコードを返すだけですか?Webサービスの例外
ユーザーはこれらの例外を決して見ることはできません。アプリケーションの他の部分にのみ適用されます。
私のグループは、サービスベースの(.NET WCF)アプリケーションを開発しており、内部サービスの例外処理方法を決定しようとしています。私たちは例外を投げるべきですか?返される例外はXMLとしてシリアル化されますか?エラーコードを返すだけですか?Webサービスの例外
ユーザーはこれらの例外を決して見ることはできません。アプリケーションの他の部分にのみ適用されます。
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!"));
}
}
私はちょっと混乱していますが、わかりにくいわけではありません。一方ではXMLとしてシリアライズされた例外を返したいと思っています。誰がこれらの例外を見るのだろうか?
通常、WCF障害契約を使用するとします。
なぜ、標準のSOAPExceptionsをスローしないのですか?エラーコードとシリアライズされたXMLの問題は、実際にエラーが発生したことを認識するために追加のロジックが必要であることです。このようなアプローチは、Webサービスの反対側で発生する必要がある特殊なログやロジックがある場合にのみ有効です。このような例では、エラー例外レポートを使用して「続行してもよろしいですか?」というフラグが返されます。
どのように投げるかにかかわらず、呼び出し側が例外を認識して対処する必要があるため、ジョブをより簡単にすることはできません。
Phil、アプリケーションのさまざまな部分がWCFを使用して互いに呼び出します。 「XMLとしてシリアライズされた戻り例外」では、関数woldの戻り値が例外オブジェクトであることを意味していました。成功はnullで示されます。
私はそれが正しい選択肢だとは思わない。
WCFの障害契約はうまくいくと思いますが、私はそれらについて何も知らない。今すぐGoogleをチェックしてください。
私でしょう、あなたはそれで大丈夫でない限り、直接クライアントに戻って例外を送るのを避けます多くの詳細が返送されます。
WCFフォルトを使用して、送信者または受信者の不具合に応じてエラーメッセージとコード(受信者の再試行、エラーアウトなどの決定に使用できるもの)を送信することをお勧めします。
これは、FaultCode.CreateReceiverFaultCodeとFaultCode.CreateSenderFaultCodeを使用して行うことができます。
私は現在このプロセスを進めていますが、WCF障害のSOAP 1.1応答が生成されているように見えます。興味があれば、ここで私の質問をチェックすることができます:
.NET WCF faults generating incorrect SOAP 1.1 faultcode values