RESTサービスでクライアントに応答を返す可能性の中で、同等に見える2つの可能性を見てきました。1つはWebApplicationException（おそらくResponseインスタンスを使用して）スローするか、もう1つはインスタンスを返すことResponseです。
結果が同じであるため、なぜ一方の可能性を他方よりも使用するのですか？これは、例外と通常の応答の間で異なる反応をするように構成されている可能性のある、使用されているRESTフレームワークに関連していますか？
16052 次
1 に答える
30
結果が同じであるため、なぜ一方の可能性を他方よりも使用するのですか？
（Java）プログラマーとして、アプリケーションの特定のルールが破られたときに例外をスローすることに慣れているからかもしれません。いくつかの文字列を数値に変換すると、NumberFormatExceptionを取得したり、配列で間違ったインデックスを使用したりArrayIndexOutOfBoundsExceptionして、許可されていないものにアクセスしたり、取得したりする可能性がありますSecurityException。「通常の応答」が可能な場合に例外をスローすることに慣れています。 tが作成されます（間違った入力または何らかの処理エラーから）。
通常の応答を返すことができない場合は、クライアントにエラー応答を返す必要があります。これは、例外をスローするか、手動で応答を作成することで実行できます。これはクライアントにとっても同じことですが、サーバー側のコードにとっても同じではありません。
例外をスローすると、コードがよりクリーンになり、推論しやすくなり、理解しやすくなります。アイデアは、をサブクラス化WebApplicationExceptionし、そこから独自の意味のある例外を作成することです（たとえばProductNotFoundException extends WebApplicationException { ... }、例外マッパーAccessDeniedException extends WebApplicationException { ... }で例外を再利用します）。
その後、毎回ビルドするのではなく、フレームワークにそれを処理させ、throw new ProductNotFoundException()後でそれをビルドするために使用された詳細に従って、コードのそのセクションで何が起こっているかを把握します。throw new AccessDeniedException()Response
于 2013-01-01T20:59:03.240 に答える