Webサービスが例外または結果オブジェクトをスローする必要があります

Question

Webサービスで例外をスローすることが良いアイデアだと完全に満足しているとは思いません。スタックトレース用でない場合は気にしません。これは私が望んでいないことではありません。

私はいくつかの実装について調査しましたが、実際にはこれについてコンセンサスが得られていないようです。たとえば、CampaignMonitorはResultオブジェクトを返しますが、他のオブジェクトは返しません。

アーキテクチャ上、戻り値オブジェクトを返すのが理にかなっているかどうかはわかりませんが、例外は確かに例外ですが、戻り値オブジェクトについて好きなことは、エンドユーザーにとってより優雅なソリューションであることです。

より良い解決策はありますか？

編集

ところで私はASMX Webサービスを使用していますが、CustomErrorsをオンにすることはオプションではありません。

Answer 1

何のスタックトレースについて話しているのですか？これを試しましたか？

ASMXサービスとWCFサービスの両方で、キャッチされなかった例外はSOAPフォールトに変換されます。どちらの場合も、スタックトレースを含まないように構成できます。実際、これがWCFのデフォルトです。

そのため、このようなエラーを返す適切な方法は、障害によるものです。フォールトを生成する1つの方法は、例外をスローして処理しないことです。

Answer 2

Webサービスを利用しているという事実が問題を混同しないようにしてください。これは単なる実装の詳細です。

通常の例外処理戦略を使用します。ベストプラクティスでは、低レベルのコードで例外をトラップしないでください。例外をそこで解決して通常どおりに続行できない限りです。ユーザーにエラーを通知できるように、プレゼンテーションレイヤーに対して例外を発生させる必要があります。

したがって、Webサービスに適用される場合、一般的に例外をスローします（その結果、SoapFaultが発生します）。これにより、呼び出し元のクライアントコードは、組み込みの例外処理標準を使用してそれを処理できます。

Answer 3

1つのアプローチは、システムエラーとビジネスエラーを分離することです。 （システムエラー：不正な形式のリクエスト、不正なユーザーなど。ビジネスエラー：メソッドUpdateCarsでエラーが発生し、ユーザーは車を所有していません。）

ビジネスエラーの場合、エラーの説明を含む応答オブジェクトを返します。システムエラーの場合、例外をスローします。

Answer 4

少し明確にできますか？ Webサービスのサーバー側は例外をスローできます。 Webサービスのサーバー側は、クライアント側にメッセージを返すことができます。そのメッセージにはエラー情報が含まれている場合があり、そのエラー情報には例外の詳細が具体的に含まれている場合があります。またはそうでないかもしれません。クライアント側では、通常、サーバーからのメッセージを処理するために生成されたプロキシがあります。応答にエラー情報が含まれている場合、このプロキシは例外を生成する場合があります。

このシナリオのどの部分について疑問に思っていますか？

Answer 5

一般に、例外をスローする方が、結果を返すよりも優れた設計パターンだと思います。 次のパターンをWebサービスとして公開されている各メソッドに適用することにより、スタックトレースを非表示にするために、Webサービス内で行う必要があると思います。

  

public void MyWebServiceMethod（）   {
    試してみる
    {

 ///Do something that may cause an error

     

} catch（Exception ex）
     {         新しいApplicationExceptionをスローします（＆quot;ユーザーフレンドリー   例外の説明＆quot;）;

     

}

     

}

またはあなたも

  

catch（Exception ex）{       元を投げる; }

例外を再スローすると、Webサービスのクライアントから元のスタックトレースが非表示になります。

Answer 6

なぜあなたは両方ができないのか分かりませんか？例外をキャッチし、ログに記録して（DBまたはファイルに）、エラーコードを返します。そうすれば、Webサービス呼び出しの正常な実行とエラーの通知が得られ、さらにデバッグできる場所が他にもあります。