Javaリサーチの公開(jdeep)-exception

checked , unchecked exception

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

OutOfMemoryError, ThreadDeath

ソース:https://madplay.github.io/post/java-checked-unchecked-exceptions
checked Exception
主に外部の影響によるものであり,プログラム利用者の動作によって生じることが多い.
コンパイル時に表示できる例外
(FileNotFoundException、ClassNotFoundException、DataFormatExceptionなど)
コンパイル時に確認するには、直ちに異常処理を行う必要があります.
Unchecked Exception
通常は、予知不可能およびリカバリ不可能な例外です.主に外部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に設定します.

いじょうでんぱ

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

画像ソース: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が見つかるまで上流に転送されます.
最後のプライマリ・エラーから最後のプライマリ・エラーに移行したら?スタックトラッキングを表示し、スレッドを閉じます.

Custom例外はいつ使えばいいですか?例外コストの良い文章

https://tecoble.techcourse.co.kr/post/2020-08-17-custom-exception

スプリングポリシーから見た例外リカバリ

JDBCを使用する場合の例外処理文.
SQL異常の原因を1つずつチェックしています.
これらの問題に加えて、各データベースには異なる例外ステータスコードがあるため、データベースが変更された場合はステータスコードを変更する必要があります.

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);
}

Springは、データ整合性ViolationException(データバインドエラー)という例外を提供します.
これはJDBCのSQLExceptionよりも明確です.
意味が明確になるだけのメリットではありません.

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

もう一つの利点は
明確なエラーが渡された以上、catch文に「できれば修復を試みる」ポリシーを記述できます.
リカバリポリシーにcatchロジックを記述できます.

try-with-resources

try-catch-finally

    	DataInputStream dis = null;
        FileInputStream fis = null;

        try {
            fis = new FileInputStream("123.txt");
            dis = new DataInputStream(fis);
              ...
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            try {
                if(dis!=null)
                    dis.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }

try-with-resources

        try(FileInputStream fis = new FileInputStream("123.txt");
        DataInputStream dis = new DataInputStream(fis)) {
            ...
        } catch (IOException e) {
            e.printStackTrace();
        }

コード可読性

戻るために()リソースを閉じる必要があるが、最初のclose()にチェックされていない例外が発生した場合、2番目のclose()は返されません.(予定通りにいかない場合があります.)

finallyも使用できます.