問題タブ [finally]

現在スローされている例外を取得する方法はありますか (存在する場合)?

コードの量を減らして、タスクの再利用を次のように適用したいと思います。

それを次のコードに置き換えます。

このシナリオは可能ですか？

ありがとう

このコードを考えると：

言語仕様は への呼び出しの戻り値を定義していtest()ますか? 言い換えれば、すべての JVM で常に同じですか?

Sun JVM では戻り値は ですが2、これは VM に依存しないことを確認したいと思います。

finally例外処理のブロックは正確に何を実行しますか？

LockDevice（）が失敗し、独自に例外をスローする可能性がある次のコードについて考えてみます。finallyブロック内から例外が発生した場合、C＃ではどうなりますか？

この質問はしばらくの間私を悩ませますが、まだ完全な答えは見つかりませんでした (たとえば、これは C# の外部または内部の使い捨てリソースを try/finally で初期化するためのものです)。次の 2 つの Java コード フラグメントを検討してください。

そして第二のバリエーション

私が心配しているのは、リソースが取得された瞬間 (ファイルが開かれたときなど) にスレッドが多少中断される可能性があることですが、結果の値はそれぞれのローカル変数に割り当てられません。上記の点でスレッドが中断される可能性があるシナリオは他にありますか?

1. InterruptedException (例: Thread#interrupt() 経由) または OutOfMemoryError 例外がスローされる
2. JVM の終了 (例: kill、System.exit() 経由)
3. ハードウェア障害 (または完全なリストについては JVM のバグ :)

2番目のアプローチはやや「慣用的」であると読みましたが、上記のシナリオではIMOに違いはなく、他のすべてのシナリオでは同等です。

だから質問：

2つの違いは何ですか？リソースの解放を懸念している場合 (特にマルチスレッド アプリケーションの場合)、どちらを選択する必要がありますか? なんで？

回答をサポートする Java/JVM 仕様の一部を教えていただければ幸いです。

重複の可能性：
Javaでは、最終的にトランプを返しますか？

以下の例では、

出力は次のとおりです。

catchのreturnステートメントにもかかわらずFinallyが出力されるのはどうしてですか？

私の同僚はnull、finally ブロックで参照を設定します。これはナンセンスだと思います。

どう思いますか？

私は次の例について考えます。しかし、finallyブロックの重要性を理解できませんでした。これら2つのコードサンプルの実行の違いを教えてください。また、実際の例も役立ちます。

サンプル1：

サンプル2：

finallyブロックの動作を理解するために、7 つのテスト ケースを作成しました。どのようにfinally機能するかの背後にあるロジックは何ですか?

なぜbuilder = null機能しないのですか？

( in builder.append("+1")trySeven ()) が機能しないのになぜ機能するのですか?count++

finally例外がスローされた結果として、コードがハンドラーのコンテキストで現在実行されているかどうかを判断することは可能ですか？私はこのIDisposableパターンを使用して入口/出口のスコーピング機能を実装するのが好きですが、このパターンに関する1つの懸念は、の本体で例外が発生した場合にスコープの終わりの動作を必ずしも発生させたくない場合があることですusing。私はこのようなものを探しているでしょう：

これを実現する方法は他にもありますが（特定の動作で呼び出しを囲む関数にデリゲートを渡す）、IDisposableパターンを使用してそれを実行できるかどうか知りたいです。

実際、これは明らかにここの前に尋ねられ、答えられました。非常にハック的な方法で検出することが可能です。私は実際にはそのテクニックを使用しませんが、それが可能であることを知るのは興味深いことです。