問題タブ [try-finally]

グラフィックス コンテキストを適切に破棄する方法 - と を使用する必要がtryありfinallyますか? 簡単な例:

編集

これは、java.awt.Window クラスの例です。

ご覧のとおり、使用されるコンストラクターは非常に単純ですがtry、finallyそれでも終了します。したがって、それらを使用することは良い習慣になると思います。

私の TFS2012 ビルド ワークフローには Parallel アクティビティがあり、いくつかのブランチ内には try-finally アクティビティがあります。1 つのブランチが失敗した場合 (たとえば、CodeAnalysis を使用したコンパイルで CodeAnalysis エラーが検出された場合)、他のブランチはキャンセルされます。ただし、分岐がブロックを持つ try ブロック内にある場合finally、finally ブロックが実行され、30 秒以上かかる場合、キャンセルは次のように失敗します。

BuildWarning: The workflow instance accepted a stop request but did not complete within 00:00:29.9922015. This may indicate an AsyncCodeActivity is active that does not support cancellation.

このようなメッセージは避けたいので、次のようにします。

1. try-finally内部で例外が発生したときに finally が実行tryされ、すべてがキャンセルされたときに実行されないアクティビティをどうにかして持つことはできますか?
2. そうでない場合は、ワークフローがキャンセルされifたブロック内に追加し、長いことをしたくありません。finallyワークフローがキャンセルされたことを知るにはどうすればよいですか?

編集:このパターンは、TFS2012 に付属する DefaultTemplate.11.1.xaml にも表示されますTryCatch.Finally。

finally を使用して「リターン後」にコードを持つ可能性を発見しました。ここにいくつかの例を示します。

（私の意見では、はるかに怠惰な）代替手段として：

それで、問題は、どちらがより速く、より読みやすいかということです。はい、この場合、私は本当に BufferedReader を閉じています。

finally ブロックで何かが起こった場合に try ブロック内で戻るのは得策ではないと思います。誰かの頭を叩く前に、実行の順序を確認したいだけです!

Java 言語仕様、セクション §14.20.2によると

finally ブロックを含む try ステートメントは、最初に try ブロックを実行することによって実行されます。次に、選択肢があります。

• try ブロックの実行が正常に完了すると、finally ブロックが実行され、次の選択肢があります。
  • finally ブロックが正常に完了すると、try ステートメントは正常に完了します。
  • finally ブロックが理由 S で突然終了した場合、try ステートメントは理由 S で突然終了します。

それを正しく解釈すると、try ブロックの実行後に最終的に呼び出されますが、これがどのように機能し、なぜ出力を得たのか、

これがどのようにして出力 10 を生成したかを知りたいです。

try ブロックが実行され、return ステートメントが検出されたときに、出力値が既にスタックにプッシュされてから、finally ブロックが実行されます。

return が最初に検出され、次に finally ブロックが実行されることはわかっていますが、出力は 10 ですが、 jvm はどのように解釈するか、try finally ブロックは jvm によってどのように処理または変換されるのでしょうか?
jvm は GOTO セクション ジャンプ セクションを使用して最終セクションに移動しますか、それともスタックは既に維持されていますか?

C#.NET では、次の例を見てみましょう

ここで、メソッド C が長時間実行されるプロセスであるとしましょう。

TakeAction を呼び出したクライアントは、メソッド C が呼び出される前、またはメソッド C が呼び出された後、または完了した後に戻り値を取得しますか?

私はコードを持っています:

なぜ 1 が印刷されるのか理解できません。