トビーのスプリングStudio(4)-例外

4.1消えたSQLException

恥ずかしい異常処理(1)

try{
	...
}catch(SQLException e){
} // 예외를잡고 아무것도 하지않는 처리방식 

例外が発生しても無視されるので、例外が発生するよりも状況が悪い.
システムエラーや奇妙な結果が出る可能性があり、原因を特定するのは難しい.

気まずい異常処理方法(2,3)

try{
	...
}catch(SQLException e){
	System.out.print(e)
}   

try{
	...
}catch(SQLException e){
	e.printStackTrace();
}  

他のログまたはメールで上書きされる可能性があります
すべての例外は、適切なリカバリ、中断、オペレータまたは開発者に明確に通知する必要があります.
それを投げ出したほうがいい.
スタック領域のスタックをスタックしてポップアップしてスタックフレームを出力

無意味で無責任なthrows

public void method1() throws Exception{
	method2();
}
public void method2() throws Exception{
	method3();
}
public void method3() throws Exception{
	...
}

何が起こるかに関する有意義な情報は得られません.
リカバリ可能な例外の処理に失敗しました

いじょうでんぱ

メソッドエラー
メソッドは、エラー情報、タイプ、およびポイントを含むオブジェクトを作成し、ランタイムシステムに渡します.そしてこれを例外と形容します.
メソッドが異常を投げ出すと、ランタイムシステムは異常を処理するものを探してみます.

画像ソース:https://docs.oracle.com/javase/tutorial/essential/exceptions/definition.html
Call stack=例外が発生したメソッドのリストを呼び出す
エラーが発生したメソッドを達成するためにcallスタックを使用して到着します.

画像ソース:https://docs.oracle.com/javase/tutorial/essential/exceptions/definition.html
ランタイムシステムは、エラーメソッドから呼び出された逆シーケンスcallstackに従って、異常を処理できるコードを決定します.
適切な例外処理ハンドルが見つかった場合、実行時にシステムは例外をハンドルに渡します.
Exceptionを扱うHandlerが見つかるまで上流に転送されます.
最後のプライマリ・エラーから最後のプライマリ・エラーに移行したら?スタックトラッキングを表示し、スレッドを閉じます.

例外処理コスト

checked , unchecked exception

エラー(システムに異常が発生)

OutOfMemoryError, ThreadDeath

ソース:https://madplay.github.io/post/java-checked-unchecked-exceptions

Exception，checked exception（アプリケーションコードの動作異常）

Checked Exception=ExceptionのサブクラスにException(RuntimeExceptionを除く)のExceptionが継承されている
主に外部の影響によるものであり,プログラム利用者の動作によって生じることが多い.
コンパイル時に表示できる例外
(FileNotFoundException、ClassNotFoundException、DataFormatExceptionなど)
コンパイル時に確認するには、直ちに異常処理を行う必要があります.
Unchecked Exception=RuntimeExceptionが継承するException、Error、およびサブクラス
通常は、予知不可能およびリカバリ不可能な例外です.主に外部APIの使用,プログラミングエラーなどを示す.
(ArrayIndexOutOfBoundsException, NullPointerException,ClassCastException, ArithmeticException)
=タイル範囲外でnullの参照変数を呼び出し、実数を変換し、整数を0で割る
2つの明確な基準は、処理しなければならないか、処理しないかの違いです.
Checked Exceptionが発生する可能性のあるメソッドはtry~catchで包むか、throwで処理する必要があります.
逆に、Unchecked Exceptionでは明示的な例外処理は不要です.

Javaでchecked、unchecked exceptionを分割する理由

https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html
メソッドを呼び出す側は、メソッドにどのような例外が発生する可能性があるかを理解する必要があります.
したがって、javaはchecked exceptionによって、このメソッドに発生する可能性のある異常を強制的にリストします.
RuntimeExceptionでは異常の原因を説明する必要はありません
コードを記述する開発者のミスによる例外はRuntimeExceptionであるため,クライアント側(メソッド呼び出し)がリカバリしたり対応したりできるとは予想し難い.また,RuntimeExceptionはどこでも非常に頻繁であるため,すべてのRuntimeExceptionにメソッドで宣言を強制することはプログラムの明確性を低下させる可能性がある.
クライアントが例外をリカバリできると予想している場合は、checked exceptionに設定したほうがいいです.そうしないと、unchecked exceptionに設定します.

例外処理方法

リカバリ例外

IOException->ユーザーが別のファイルを使用して例外を解決するようにユーザーに指示します.ユーザーファイルを読み込めないためです.
例外をリカバリできる場合は、リカバリできる数を再試行します.

例外を回避

呼び出しの側に自分を投げつける方法、またはcatch文を使用して例外をキャプチャし、ログを保持して再び例外を投げ出す方法.
理由もなく投げ出すのは無責任な回避かもしれない.意図は明確にしなければならない.他のオブジェクトに異常を処理する責任を明確にさせなければならない.

変換例外

SQLExceptionが発生しているが、なぜSQLExceptionが発生し、ログイン名の重複エラーが発生しているのか分からない場合は、DuplicateUserIdExceptionなどの異常に切り替えて投げ出す
復旧できない異常の場合は、運転時異常としてパッケージして捨て、詳細なログを残し、管理者にメール通知を送信し、ユーザーに親切な情報を送信することが望ましい.
処理できない例外については、uncheckedexceptionにすばやく送信してください.機械で投げるな.

4.2変換異常の目的

catch、

throwsを減らす

より意味と抽象的な例外

JDBC制限

非標準SQL
lowの開始位置、数、またはクエリーに含まれる条件を指定して

ページングします.
=>SQLごとに異なるコードが記述され、特定のDBのスレーブコードとなる.

SQLException

具体的なエラーコードはDBに属する.

Spring自体にDataAccessExceptionを作成し、SQLEExceptionのエラーコードをDBにマッピングし、場合によって異なるエラーを送信します.
ORMで発生するが、JDBCで例外がない場合にも階層化が行われている.
SpringのDataAccessExceptionはSQLEExceptionをUnchecked Exceptionに変更し、不要なthrows文、DBコンテキストエラー、およびORMのみで発生する異常を低減します.

SQLExceptionとは異なり、複数のサブクラスが特定の項目を表す.
例外をより正確に伝えることができ、回復できるものをつかむことができます.

try {
	//do data operation using JDBC abstraction layer
} catch (DatalntegrityViolationException ex) {
	// Apply recovery strategy
}

JDBCロジックtryにアクセスし、リカバリポリシーのcatchロジックを記述できます.

try {
	//do data operation using JDBC
} catch (SQLException ex) {
	boolean recovered = false;
	String sqlstate = sqlex.getSQLState();
		if (sqlstate != null) {
		String classCode = sqlstate.substring(0, 2) ;
			if ("23".equals(classCode) ||"27".equals(classCode) ||
			 	"44".equals(classCode)) {
		// Apply recovery strategy
			recovered = true;
	}
}
if (!recovered)
	throw new ApplicationSpecificExceptionf("Other SQL exception", ex);
}

SQLステータス文字列を確認する方法のみです.
コードでも足りない.各RDBMSの実装オプションを考慮すべきである.