0

シナリオ：

ユーザー ID に基づく登録が必要な Web サイトの場合、ユーザー ID は一意でなければなりません。ユーザーが、すでに存在する「foo」ユーザー ID で登録しようとしたとします (他の必須フィールドを使用)。ここで、チェック済み例外を使用せずに (データベース API が重複挿入に対してスローSQLExceptionします)、未チェック例外の支持者がこの状況をどのように処理し、ID が既に選択されていることをユーザーに知らせているのだろうか?

この Web サイトが Struts にあるとしましょう (いいえ、私はプロジェクトに取り組んでいるわけではありません。それをよりよく理解しているだけです)。ユーザーは、DAO を呼び出して新しいレコードを挿入する Struts アクションに入力した情報を送信します。したがって、最終的に DAO は失敗する INSERT ステートメントを発行します。したがって、アクション (DAO を呼び出す) がこの状況を明示的に処理しない場合 (DAO メソッドは、例外を拡張する DuplicateUserIDExceptoion のようなビジネス チェック済み例外をスローすることを宣言するSQLExceptionか、メソッドがキャッチしてスローする可能性があります)、未チェックの例外でこれをどのように処理できますか? SQLException?

結論 - Java はチェック例外を必要としないという記事をたくさん読んだので、このシナリオが理解を深めるのに役立つことを願っています。私は非常に多くの記事を読んでいて、本当に非常に混乱しているので、記事を指摘しないでください. あなたが私を助けることができる最善の方法は、上記のシナリオに対する答えを提供することです.

注: 回復可能な例外的なシナリオは、チェック済みの例外 (プロジェクトで実装してきた) によって処理する必要があることは理解していますが、チェックされていない例外のみの支持者には本当に混乱しています。上記のシナリオをどのように処理しますか？

前もって感謝します。

4

2 に答える 2

4

チェックされていない例外は、チェックされた例外とまったく同じようにキャッチできます。このような場合を処理するには、次のようにします。

  1. ユーザー ID が既に存在するかどうかを確認します。その場合は、チェック済みの DuplicateUserIdException をスローします。ここでは、チェックされた例外の方が理にかなっていると思います。ただし、例外をランタイムのものにして、チェック済み例外をキャッチするようにプレゼンテーション層でキャッチすることもできます
  2. ユーザーを挿入します。SQLException が発生した場合、それが既存のユーザー ID によるものであることを正確に確認するのは簡単ではありません。さらに、延期された場合、コミット時に制約をチェックできます。この例外は、2 つのスレッド間で競合状態が発生した場合にのみ発生するため、めったに発生しません。したがって、技術的なランタイム例外のように扱い、一般的なエラー メッセージを表示します。
于 2012-05-30T17:10:36.080 に答える
0

トランザクションを開始し、データベースにクエリを実行して ID が存在するかどうかを確認し、存在しない場合は挿入を実行してから、トランザクションをコミットしますか? 存在する場合は、ID が既に存在することをユーザーに伝えます。さらに良いことに、フォームのユーザー名フィールドのぼかしのチェックを ajax リクエストとして実行し、それが既に取得されていることを示すことができます。ID が存在するかどうかを判断するためにデータベースの例外に依存する必要があるのはなぜですか?

于 2012-05-30T17:07:43.430 に答える