[WebMethod]
属性を使用して生成された一連のWebサービスがあります。ArgumentException
引数が適切に指定されていない場合(そして適切なデフォルトを使用できない場合)、そのようなメソッドからスローすることは「グッドプラクティス」と見なされますか?その場合、サーバーとクライアントの両方にログを記録するために、この例外をキャッチして再スローする必要がありますか?
3 に答える
いいえ、.NET例外(のようなArgumentException
)はクロスプラットフォームでサポートされていないため、Webサービスから例外をスローすることはお勧めできません(Javaクライアントがどのように応答する必要があるかを考えてください)。
Webサービスで例外を示すための標準的なメカニズムは、SoapFaultです。
を使用すると、 SOAPException.asmx
をスローすると障害が発生します。
WCFに移行すると、FaultContractsを確認できます。
.Netクライアントと.Netサーバー間のリモート例外のデバッグを改善するために、構成でincludeExceptionDetailInFaultsを使用して、ネットワークを介して例外をチートおよび送信できます。これが機能するには、例外自体がシリアル化可能である必要があります。ただし、システムが本番環境に到達する前に、これをオフにすることをお勧めします。
余談ですが、呼び出し元のSOAP要求呼び出しの形式が不十分な場合(たとえば、引数に逆シリアル化できないエンティティが含まれている場合)、WebMethod
まったく呼び出されないことがよくあります。呼び出し元は障害を受け取るだけです。 (多くの場合、かなり不可解です)。
クライアントのサービスへの呼び出しからの不正な引数に対して発生した上記の障害は、呼び出し引数が検証されたときに生成される必要があります。
関連する可能性があります-リクエストが検証に合格すると、独自の内部システム状態アサーションに対して、コードコントラクトを使用して内部バグ(または、以前に発生したはずの検証の欠落)を検出することもできます。ただし、これらはクライアントに伝達されません。
これは、Webサービスの例外に関するすばらしい記事です。
例外とカスタムエラーコードの使用は、常に難しい決断です。ケースがどの程度「例外的」であり、消費者側でエラーをどのように処理する予定であるかを見積もる必要があります。例外の使用は、通常、予期しないケース(重要なパラメーターが欠落しているなど)およびビジネスのようなエラーを処理するためのカスタムエラーコードです。
更新:もちろん、これは新しいサービスを作成する場合にのみ適用されます。既存のものを変更する場合は、既存のクライアントがそれをどのように使用し、エラーコードをどのように予期するかを知る必要があります。