なぜこれを行うのか
} catch (SQLException sqle) {
sqle.printStackTrace();
} finally {
cs.close();
rs.close();
}
これの代わりに
} catch (SQLException sqle) {
sqle.printStackTrace();
}
rs.close();
cs.close();
なぜこれを行うのか
} catch (SQLException sqle) {
sqle.printStackTrace();
} finally {
cs.close();
rs.close();
}
これの代わりに
} catch (SQLException sqle) {
sqle.printStackTrace();
}
rs.close();
cs.close();
例外がスローされた場合、例外がキャッチされない限り、ブロックが実行された後にコードが実行されないためです。try
ブロック内で何が起こっても、ブロックは常に実行されます。finally
try
あなたの catch ブロックを見てください - それは throw しようとしていますDAOException
。したがって、catch ブロックの後のステートメントは、指定したサンプルでも実行されません。あなたが示したもの (ある例外を別の例外でラップする) は、1 つの一般的なパターンですが、別の可能性は、catch ブロックが「誤って」例外をスローすることです。
さらに、メソッドがスローすることを宣言したか、チェックされていない例外であるため、キャッチしない他の例外がある場合があります。IllegalArgumentException
どこかにスローされたので、本当にリソースをリークしたいですか?
例外がスローされた場合、
例外が残りのメソッド実行を中止したとしても、finally 句のコードは例外が外側に伝播するときに実行されます。
例外が catch ブロックによってキャッチされ、再スローされない限り、try/catch ブロックの後のコードは実行されません。
finally ブロック内の内容が確実に実行されるためです。たとえば、catch ブロックに別の例外があるなど、catch の後の処理は実行されない可能性があります。または、行ったことを実行して、元の例外をラップする例外をスローします。
finally キーワードは、コードが実行されることを保証します。一番下の例では、close ステートメントは実行されません。一番上の例では、それらが実行されます (あなたが望むものです!)
2 番目のアプローチは、既にメソッドから離れているため、「close」ステートメントを実行しません。
これは、リソースリークを回避する方法です
catch がコール スタック内の上位レベルの関数に例外をスローできることを考慮してください。これにより、上位レベルに例外をスローする前に final が呼び出されます。
finally ブロックは常に実行されるとは限りません。次のコードを検討してください。
public class Tester {
public static void main(String[] args) {
try {
System.out.println("The main method has run");
System.exit(1);
} catch (Exception e) {
e.printStackTrace();
} finally {
System.out.println("The finally block has run");
}
}
}
あなたの場合、コードが例外をスローする可能性があるため、finally ブロック内のコードを try/catch にラップすることをお勧めします。
} catch (SQLException sqle) {
sqle.printStackTrace();
} finally {
try {
cs.close();
rs.close();
} catch (Exception e) {
//handle new exception here
}
例外が catch ブロックから再スローされる前に、finally ブロックのコードが呼び出されます。これにより、finally ブロックに入れたすべてのクリーンアップ コードが確実に呼び出されます。finally ブロックの外側のコードは実行されません。