問題タブ [try-finally]

Java仮想マシンの仕様とコンパイルされたコードを見ると、「同期された」ブロックがJavaでどのように実装されているかがわかります。次のコード：

...この擬似コードとほぼ同等です。

...1つの例外を除いて。

何らかの理由で、例外テーブルには2つのfinallyハンドラーが表示されます。例えば：

最初のハンドラーは私が期待する場所ですが、2番目のハンドラーは実際には最初のハンドラーのfinallyブロック用であり、例外をキャッチすると同じハンドラーを実行します。次の方法では、これをうまく視覚化できません。

なぜこれなのか誰か知っていますか？それがfinallyブロックだけの場合、テーブルの2番目のエントリはそこにありません。その上、すでに例外がスローされている場合、finallyブロックを再度実行したい理由はわかりません。

ありがとう、ブランドン

コードの簡単な部分、いくつかの基本try-finallyブロックについて簡単な質問があります。

私の主な質問は次のとおりです。ブロック間で情報を渡すために、いくつかのローカル変数をfinally使用せずにブロックで例外がスローされることを発見できる方法はありますか？catch

catchこれが役立つ状況はほとんどありません。変数を設定するためだけに、醜い不要なブロックを追加したくありませんthrow Exception。最初の例は、Springまたはコンテナー管理のトランザクションメソッドを使用していて、tryブロックExceptionが発生した場合です。finallyその場合、データベースを操作するために新しいトランザクションを作成する必要があります。2番目の例は、ブロックにスローされてオリジナルExceptionがマスクされたくない場合ですが、存在しない場合は、（存在する場合は）スローします。ExceptionfinallyExceptionfinally

私はそれがすべてできることを知っていますcatchが、他の方法、Javaのメタデータまたは他の何かがありますか？また、これが1つで実行されると想定できる場合は役立つ可能性があるThreadため、現在の例外に制限されている例外を検出する方法があるかもしれませんThread。

これは、try/finally 句の動作に関するやや学術的な質問であるため、非常に一般的な例を使用しようとしました。このように try/finally 句をネストすることに危険はありますか?

closeCursor()具体的には、が before で呼び出されることが保証されているかどうかを知りたいですcloseDatabaseConnection()。悪い習慣と見なされるように、finally 句をネストする理由はありますか?

Swing ベースのデスクトップ アプリケーションで JPA を使用しています。これは私のコードがどのように見えるかです:

try - catch - finallyトランザクションを必要とするすべてのメソッドにこれを使用しています。を持つメソッドを除いて、期待どおりに機能していSwingUtilities.invokeLater()ます。

finally新しいスレッドのすべてのコードが実行される前に到達します。したがって、 内SwingUtilities.invokeLater()に JPA 操作がある場合、トランザクションがコミットされているため失敗します。

try - catch - finally内部のコードを含むすべてのコードが実行された後にのみトランザクションがコミットされることを確認するために従うことができる一般的なユースケースはありSwingUtilities.invokeLater()ますか?

私は今日、このようなコードを持っている小さな問題に遭遇しました。それは私を少し不快にさせました...

このような実装は、で例外が発生し、tryそれを処理する呼び出し元に再スローされるという点で優れた方法であるかどうか疑問に思います。これは以下のコードと同等ですか？