DAOパターンの例外と戻りコード

Question

Java）での例外の乱用に関する多くの説明と、アプリケーションのさまざまなレイヤーを介して例外をバブルアップさせる方法を読んだ後、私はそうしないところに行きましたアプリケーションで発生する可能性のある潜在的なエラーをどう処理するかを知っています。

基本的に、DAOパターンを使用してデータベース内のデータにアクセスするWebサービスがあります。すべてのデータベースアクションはSQLExceptionをスローできます。今日の時点では、try catchを使用してSQLExceptionをキャッチし、次にExceptionDAOと呼ばれる特定の定義済み例外を使用して、Webサービスがユーザーに正しいメッセージを返すように処理します（私のウェブサービスのモバイルアプリケーション）。

どのように例外が例外的であり、制御フローで使用されるべきではないかについてたくさん読んだ後、私はすべてのエラーを処理するために何をすべきかについて混合理解を思いつきました：

発生する可能性のあるもの（ユーザー名が既に存在するなど）にはリターンコードを使用するため、DAOパターンに準拠するには、代わりにビジネスオブジェクトをパラメーターとして渡します。また、コード+ビジネスオブジェクトを返す特定のペアを使用することもできます。次に、Webサービスは戻りコードを使用して特定のメッセージを表示します。
チェックされた例外を使用して、予測できないすべてのことが起こり、Webサービスにバブリングして、メッセージを処理してユーザーに返すようにします。（例：予測できないSQLException：接続が中止されました）
未チェックの例外もバブルアップし、この場合は404エラーのようなものを表示します。

ヌルパターンも確認しましたが、この特定の状況にはあまり適していないと思います。また、ユーザーにあまり多くの情報を提供しないことも気になります。むしろ、ポイント情報に直接役立つ情報です。実際、ウェブサービスから返されたメッセージはモバイルアプリケーションで使用され、エンドユーザーにメッセージを表示します。

私が抱えている問題について十分に明確になったことを願っています。皆さんの回答を楽しみにしています！

N.B. ：これは私がstackoverflowに投稿した主題の再投稿です。これはプログラミングに関係し、言語固有の問題ではありません。

Tim Ojo · Answer

は、コードで処理できない条件が発生した場合にのみ例外をスローする必要があるという従来の知識では、/の定義に重点を置く傾向があります例外条件ただし、例外がhandleに与える意味の定義は無視してください。プロセスは特定のノードと通信している例外に遭遇するかもしれず、その代わりにその要求をバックアップノードにリダイレクトすることによって例外をhandleするかもしれません。ただし、ユーザーが値を入力した結果として一意の制約が原因でテーブルにエントリを作成する呼び出しが失敗した場合、真にhandleできるエンティティはユーザーのみです。したがって、これはコードで処理できないため、例外をスローする根拠となります。

コードのセマンティクスも重要です。新しいユーザーエントリを作成する例に固執します。 isAvailableUserName(userName)の呼び出しは、userNameがすでにデータベースに存在する場合は例外をスローしませんが、createNewUser(userName)の呼び出しはおそらく存在します。リターンコードを使用する代わりに例外をスローする理由の1つは、リターンコード自体が不十分な情報を提供し、ルックアップテーブルまたは列挙型が必要になるため、依存関係の磁石となるためです。一方、例外はより説明的であり、メッセージ、バックトレース、ネストされた例外などが含まれます。例外により、コードがすっきりします。条件をテストするためだけに存在するネストされたifをたくさん持つ代わりに、コードは想定どおりに機能し、悪いことが発生すると実行を停止することができます。 Robert C. Martinは、彼の著書「Clean Code」で、エラー処理によってコードのロジックが不明瞭にならないようにすべきだと述べています。戻りコードにより、コードの呼び出し元は呼び出しの直後にエラーをチェックする必要があるため、コードの清浄度は呼び出し元にも適用されます。これは簡単に忘れられたり無視されたりする可能性があるため、良い方法ではありません。ただし、例外は無視できませんhandledでなければなりません。

Robert Harvey · Answer

例外について誤解しているようですので、まずはそれらをクリアしてみましょう。

コードで処理できない条件が発生したときに例外をスローします。

たとえば、コードがファイルを開いてそのファイルで何かを行うことになっているが、ユーザーが存在しないファイルへのパスを指定した場合は、例外をスローする必要があります（またはスローされた例外に呼び出しを許可しますstack）は、ユーザーがコードを実行し続けることができない条件を作成したためです。

例外タイプをログに記録または変更する場合は、例外を再スローします。

たとえば、例外をログに書き込むか、例外条件を修正しない同様のことを行う場合は、例外をキャッチしてログに記録し、再スローします。おそらく、特定のコードにより適切な例外を使用します。

最後に、ソフトウェアのガイドラインとベストプラクティスは、ガイドラインにすぎません。それらを尊重しますが、特定の状況に最も適したことを行います。それがガイドラインを破ることを意味するならば、それならそうです。ガイドラインがプログラミングの邪魔にならないようにしてください。プログラミングには絶対的なものはありません。