4

例外処理に関して多くの議論がなされてきたことは知っていますが、私の状況に固有のアドバイスが必要です。

現在、レイヤーを使用したSpring MVCアプリケーションに取り組んでいます。Controller->Services->DAOサービス クラスは、主に 2 種類の例外HibernateExceptionとIOException.

HibernateExceptionトランザクションが成功しなかった場合、サービスはロールバックを実行する必要がありIOException、それはチェックされていない例外であり、キャッチまたはスローする必要があるため、最初のオプションを好みます。

スタック内でこれらをさらに処理するより良い方法は次のとおりです。

  1. これらの例外をコントローラーに再スローし、コントローラーで ExceptionHandlerHTTP エラーコード 500 を送信する必要があります
  2. または、catch ブロックで通常のJSON responseオブジェクト、設定status=failure、および適切なエラー メッセージを作成し、これをコントローラーに返しますか?
4

2 に答える 2

9

例外処理の規則:

例外を処理する最良の方法は、それを処理しないことだということわざがあります。

のレイヤーSpringの慣例では、処理メカニズムは として知られています。またはレイヤーで例外が発生した場合は、それをレイヤーにポップアップする必要があります（daoおよびサービスレイヤーのメソッドシグネチャを追加するのが最も一般的な方法です）。レイヤーのみが例外を処理する必要があります。controller<->service<->daoExceptionBubble updaoservicecontrollerthrows XXXExceptioncontroller

これは、 spring を使用して REST の例外を処理する方法の優れたチュートリアルです。

HTTP ステータス コード 500 またはステータス付きの JSON オブジェクトを送信します。

でAPIを書いているようですねSpring MVC。API を作成するときは、適切な規則に従う必要があります。内部サーバー エラーの場合、 code を含む HTTP 応答を送信することは世界的に受け入れられています。これは、内部サーバー エラー500を意味します。

JSONこの場合、応答を送信してはならないものには多くの原因があります。主な原因の 1 つは、API クライアントの暗黙の想定です。200これは、JSONオブジェクトを含むコードを含む HTTP 応答であり、すべてが正常に行われたことを意味します。したがって、クライアント側のビジネス ロジックは、最終的に間違っているという仮定を反映する可能性があります。

APIここでは、いくつかの有名な組織のエラー コード規則を確認できます。

于 2013-06-03T15:28:06.203 に答える
2

あなたはまだクライアントを作成する段階に達していないので、自分で 100% を選択できると思います。

その場合、1 を使用することをお勧めします。主な理由は、正しいステータス コードを使用すると、API で大いに役立つだけでなく、問題を非常に簡単に解決できるからです。エラー処理用のきちんとしたコードを書くことができます。最初のポイントを使用する必要があるもう 1 つの主な理由は、他の API、リソース、または Web アプリケーションのエラー処理を簡単に再利用できるためです。

たとえば、すべてのエラーを含む列挙型と、それらをどのステータス コードと見なすか、およびどのログ レベルにするかを含めることもできます。

public enum ExceptionMapping {
IllegalArgumentException(IllegalArgumentException.class, 400, LogLevel.ERROR),

あなたの目標が不明なクライアント向けのきちんとした API を構築することである場合は、REST レベル 3 ( http://martinfowler.com/articles/richardsonMaturityModel.html ) についてさらに読むことをお勧めします。ここには、ハイパーメディア リンクを含めて、クライアントが完全な API を「参照」します。クライアントはよりスマートにする必要があるため、より多くの作業が必要になりますが、クライアントが気付かないうちに API の大部分を壊すなど、非常に優れた機能を提供できます。

于 2013-06-03T15:27:06.690 に答える