問題タブ [finally]

編集:私は答えのコードを見てきました:それらのどれも私が望むことをしません(私はチェックしました)。ネイティブの C# で私がやりたいことを行う方法はないようです。.NETがサポートしていることを考えると、それは災害ではなく、残念なことだと思います（受け入れられた回答を参照）。

皆さんありがとう。

このような c# コード (デバッガー以外では実行されないテスト フレームワークの一部) があり、スタックの巻き戻された部分でコードをデバッグするのが非常に面倒になるため、実際に例外をキャッチしないようにしています。

これを行うためのより良い方法はありますか？

解決策は、キャッチされていない例外に関して、デバッガーの下でそれとまったく同じように動作する必要があります。最初のチャンス例外が 1 つだけ発生し、catch ブロックではなく、例外が最初にスローされた時点でデバッガーが中断する必要があります。

具体的には、キャッチされていない例外でデバッガーが in side MightThrow を停止する必要があります。

以下は、デバッガーが正しい場所でブレークしないため、機能しません。

そして、これはスタック情報を失う (また、間違った場所で壊れる) ため、機能しません。

Dscope(failure)でブロックを使用できることを知っていました

私は、同僚がコード内の奇妙な動作をデバッグするのを手伝っています。次のサンプルは、これを示しています。

このサンプルは何を返しますか?

finally ブロックのせいで "def" を返していると思うかもしれませんが、実際には "abc" を返しますか? コードをステップ実行し、finally ブロックが実際に呼び出されていることを確認しました。

本当の答えは、そもそもこのようなコードを書くべきではないということですが、私はまだ動作について困惑しています。

編集：いくつかの回答に基づいてフローを明確にする。

コードをステップ実行すると、finally が return の前に実行されます。

の重複: try { return x; で実際に何が起こるか } 最後に { x = null; } 声明？

これは、TCPサーバーをセットアップするために使用するコードです

同じ宛先で Bind を呼び出すと、ポートが既に使用されているため、例外が発生します。その関数を 2 回呼び出すと、その例外が発生します。

問題 - Catch{} ステートメントの後、コードは例外をキャッチしたにもかかわらず、Finally{} に続くのはなぜですか? メッセージボックスの後に関数を終了させたい.「return」で試しましたが、まだfinally{}ブロックに続きます。

真/偽の答えを期待していた別のインタビューの質問で、よくわかりませんでした.

複製

• .NET では、catch ブロックで何かが失敗した場合、最終的には常に呼び出されるのでしょうか?
• finally ブロックは常に実行されますか?
• .net try..finally ブロックで finally が実行されない条件
• Try ブロックで値を返すと、Finally ステートメントのコードは実行されますか?

次のコードを使用します。

これにより、次の出力が得られます。

私の質問は:なぜ未処理の例外テキストが最終の前に発生するのですか? 私の考えでは、この例外が処理されていないことを知る前に、スタックが巻き戻されるときに finally を実行する必要があります。Sleep() の呼び出しに注意してください。これらは、ハンドルされていない例外が出力された後に発生します。

1. 未処理の例外テキスト/メッセージ
2. 最後にブロックします。
3. アプリケーションを終了する

C# 標準の §8.9.5 によると、この動作は正しくありません。

• 現在の関数メンバーで、スロー ポイントを囲む各 try ステートメントが調べられます。各ステートメント S について、最も内側の try ステートメントから始まり、最も外側の try ステートメントで終わるまで、次のステップが評価されます。
• • S の try ブロックがスロー ポイントを囲み、S に 1 つ以上の catch 句がある場合、catch 句は出現順に調べられ、例外に適したハンドラーが検索されます。例外の種類または例外の種類の基本型を指定する最初の catch 句は、一致と見なされます。一般的な catch 句 (§8.10) は、あらゆる例外タイプに一致すると見なされます。一致する catch 句が見つかった場合、その catch 句のブロックに制御を移すことによって、例外の伝播が完了します。
• • それ以外の場合、S の try ブロックまたは catch ブロックがスロー ポイントを囲み、S に finally ブロックがある場合、制御は finally ブロックに転送されます。finally ブロックが別の例外をスローした場合、現在の例外の処理は終了します。それ以外の場合、制御が finally ブロックの終点に到達すると、現在の例外の処理が続行されます。
• 現在の関数メンバー呼び出しで例外ハンドラーが見つからなかった場合、関数メンバー呼び出しは終了します。上記の手順は、関数メンバーが呼び出されたステートメントに対応するスロー ポイントを使用して、関数メンバーの呼び出し元に対して繰り返されます。
• 例外処理が現在のスレッドのすべての関数メンバー呼び出しを終了し、スレッドに例外のハンドラーがないことを示す場合、スレッド自体が終了します。このような終了の影響は実装定義です。

どこが間違っていますか？(私はいくつかのカスタム コンソール エラー メッセージを持っていますが、これは邪魔です。些細なことで、面倒で、言語に疑問を抱かせます...)

これを見つけるためにildasmを実行しました：

これと同等の IL コードを生成します。

問題は、なぜ最終的に null をチェックするのかということです。finally ブロックは、try ブロックが実行された場合にのみ実行され、try ブロックは、Simple コンストラクターが成功した場合 (つまり、例外がスローされない場合) にのみ実行されます。この場合、simp は非 null になります。(Simple コンストラクターと try ブロックの先頭の間に何らかのステップが介在するのではないかという懸念がある場合、それは本当に問題になります。例外がスローされて、finally ブロックの実行がまったく妨げられる可能性があるからです。)それで、なぜ一体？

using ステートメントが try-finally よりも優れているかどうかの議論は (お願いします) 脇に置いて、try-finally ブロックを次のように記述します。

何が起こっても特定のコードを実行したいという状況がありますが、後で処理するために例外もスタックに渡される必要があります。次のとおりです。

例外を無視するだけですか、それとも例外を渡しますか？私のテストは、彼らがまだ受け継がれていることを示しているようですが、私は狂っていないことを確認したいと思います。

編集：私の質問は、finallyがいつ実行されるかについてではなく、例外がまだ上向きにスローされるかどうかについてですが、それは今答えられています。

興味深いコードに出くわしたとき、私が支援している代替のオープンソース JVM ( Avian )のあいまいなテストケースを考え出そうとしていましたが、コンパイルされなかったことに驚きました:

最も明白なコード パス (私が目にする唯一のもの) は、a = 1 を実行して a を返すように "試行" し (初めて)、最後に実際に a を返すを実行することです。ただし、 javac は、「a」が初期化されていない可能性があると不平を言っています。

私が考えることができる唯一のことは、別のコード パスを引き起こす/許可する可能性があるということです。しかし、これらがコードのこの場所で発生する可能性があるケースは考えられません。

Java 標準の詳細に精通している人は、これに光を当てることができますか? これは、コンパイラが保守的であるため、そうでなければ有効なコードであるものをコンパイルすることを拒否しているという単なるケースですか?それとも、ここで何か奇妙なことが起こっているのでしょうか?

検討、

サンプルコードは「1」を出力します。しかし、iの値はfinallyブロックで3に変更されます。'i'の値が3に変更されなかったのはなぜですか？

ありがとうございました、