Javaと例外処理
SQLException例外がリポジトリ・レイヤで発生した場合、それをRuntimeException例外に変換して再放出するのはなぜですか?Javaと例外処理を見てみましょう!
Throwable:トップレベル異常
Error:メモリ不足や深刻なシステムエラーなど、アプリケーションでリカバリできないシステム異常
Exception:異常チェック RuntimeException:Unchecked異常 例外処理-Jump to Java
Checked例外を宣言する場合は、throws例外を宣言する必要がありますが、コンパイル時にエラーをキャプチャする利点があるため、安全です.
しかし,実際の作業では,Checked異常が発生すると,受け取ってUnchecked異常に変換して投げ出す.
実務でChecked例外よりUnchecked例外の方が人気がある理由は何ですか?
ほとんどの例外は修復できません.リポジトリに例外が発生した場合に、例外をサービス・レベルまたはコントローラ・レベルにアップグレードすると、処理できません.ただし、チェック異常は常にthrowを指定する必要があるため、サービス層またはコントローラ層にも異常をキャプチャまたは処理する義務がある.
たとえば、リポジトリ階層でSQLExceptionが発生した場合に例外が放出されるとします.throwsのため、サービス層、コントローラ層も例外を処理するか、throws SQLExceptionを指定する必要があります.
java.sql.SQLExceptionのような特定の技術に依存するため、Springコアと呼ばれるOCP、DIによってインプリメンテーションを変更することは困難である.
基本的にUnchecked(RuntimeException)→以降汎用異常処理で処理すればよい. 論理的には、意図的に投げ出す異常(キャプチャして処理しなければならない問題)に対してのみChecked異常 が使用される. checked例外として宣言された場合は、すぐに処理します.Unchecked(RuntimeException)として宣言された場合は、先に共通処理例外の部分を作成して処理します. 共通点:サーボフィルタ、スプリングコネクタ、スプリング上のController Addを使用
データベースにエラーが発生した場合、データベースはエラーコードを返し、そのエラーコードを受信したJDBCDriverはSQLExceptionを生成します.場合によっては(重複鍵例外の場合)例外のみを処理したい場合は、エラーコードを比較して独自の例外を放出または処理できます(Unchecked例外の場合、Runtime Exception).
しかし、これは最善の方法ですか?エラーコード(Error Code)は、異なるデータベースで異なる
他のデータベースに変更する場合は、変更するデータベースのエラーコードと一致するようにすべてのエラーコードを変更する必要があります. データベースあたりのエラーコードの種類が多すぎます. エラーコードを発生する可能性のあるすべての状況と比較し、異常処理を行うのは効果的ではありません.
ex) h2 database error code
Springでは,データアクセスに関する例外を抽象化することで,開発者の作業量を軽減する.
また、既存のデータベースは特定のデータベースに依存しており、データベースを変更するには多くのコードを変更する必要がありますが、スプリング定義の例外は特定のテクノロジーに依存しません(抽象的であるため!)JDBCテクノロジーでもJPAテクノロジーでもspringinが提供する例外を使用すればよい.
DataAccessExceptionはRuntimeExceptionを継承しており、BasdSql GrammarException、DuplicateKeyException、Query TimeoutExceptionなどのデータアクセスに関連する様々な例外を抽象化したチェックされていない例外です.
DataAccessException docs
Spring SpringExceptionTranslatorをサポートすることで、対応するSpringデータ・アクセス・レイヤの例外に変換して返します.(これは、誤ったコードを無知に比較してRuntimeExceptionを投げ出す必要がないことを意味します!)
最近のほとんどのライブラリでは、デフォルトのUncheckedとRuntime Exceptionが提供されています.また,実際の運用では,JPA技術を用いてデータアクセスを処理し,JPAもRuntime Exceptionを用いる.業務上はあまり使われませんが、必ず知っておきましょう!
Spring DB 1編-データアクセスの重要な原理
死刑囚開発者-Springの各種異常処理方法
Exception hires
Throwable:トップレベル異常
Error:メモリ不足や深刻なシステムエラーなど、アプリケーションでリカバリできないシステム異常
Exception:異常チェック
Checked例外を宣言する場合は、throws例外を宣言する必要がありますが、コンパイル時にエラーをキャプチャする利点があるため、安全です.
しかし,実際の作業では,Checked異常が発生すると,受け取ってUnchecked異常に変換して投げ出す.
実務でChecked例外よりUnchecked例外の方が人気がある理由は何ですか?
Checked異常の問題
1.throwsは常に明記されています。
ほとんどの例外は修復できません.リポジトリに例外が発生した場合に、例外をサービス・レベルまたはコントローラ・レベルにアップグレードすると、処理できません.ただし、チェック異常は常にthrowを指定する必要があるため、サービス層またはコントローラ層にも異常をキャプチャまたは処理する義務がある.
2.特定の依存関係を生成する。
たとえば、リポジトリ階層でSQLExceptionが発生した場合に例外が放出されるとします.throwsのため、サービス層、コントローラ層も例外を処理するか、throws SQLExceptionを指定する必要があります.
java.sql.SQLExceptionのような特定の技術に依存するため、Springコアと呼ばれるOCP、DIによってインプリメンテーションを変更することは困難である.
チェック例外はそのまま使いましょう!
抽象スプリングとデータアクセス異常
データベースにエラーが発生した場合、データベースはエラーコードを返し、そのエラーコードを受信したJDBCDriverはSQLExceptionを生成します.場合によっては(重複鍵例外の場合)例外のみを処理したい場合は、エラーコードを比較して独自の例外を放出または処理できます(Unchecked例外の場合、Runtime Exception).
しかし、これは最善の方法ですか?
他のデータベースに変更する場合は、変更するデータベースのエラーコードと一致するようにすべてのエラーコードを変更する必要があります.
ex) h2 database error code
Springでは,データアクセスに関する例外を抽象化することで,開発者の作業量を軽減する.
また、既存のデータベースは特定のデータベースに依存しており、データベースを変更するには多くのコードを変更する必要がありますが、スプリング定義の例外は特定のテクノロジーに依存しません(抽象的であるため!)JDBCテクノロジーでもJPAテクノロジーでもspringinが提供する例外を使用すればよい.
DataAccessException
DataAccessExceptionはRuntimeExceptionを継承しており、BasdSql GrammarException、DuplicateKeyException、Query TimeoutExceptionなどのデータアクセスに関連する様々な例外を抽象化したチェックされていない例外です.
DataAccessException docs
SpringExceptionTranslator
Spring SpringExceptionTranslatorをサポートすることで、対応するSpringデータ・アクセス・レイヤの例外に変換して返します.(これは、誤ったコードを無知に比較してRuntimeExceptionを投げ出す必要がないことを意味します!)
// SpringExceptionTranslator 예시
DataAccessException e = exceptionTranslator.translate(”save”, save_sql, e);
SpringExceptionTranslator docs 最近のほとんどのライブラリでは、デフォルトのUncheckedとRuntime Exceptionが提供されています.また,実際の運用では,JPA技術を用いてデータアクセスを処理し,JPAもRuntime Exceptionを用いる.業務上はあまり使われませんが、必ず知っておきましょう!
Reference
Spring DB 1編-データアクセスの重要な原理
死刑囚開発者-Springの各種異常処理方法
Reference
この問題について(Javaと例外処理), 我々は、より多くの情報をここで見つけました https://velog.io/@jk05018/Java와-예외-처리テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol