問題タブ [try-finally]

私が管理しているいくつかのアプリの多くの場所で、begin/end の使用を回避するor文でtry/finallyortry/exceptブロックを使用するコードを見つけました。for loopif

次のコードを検討してください (本番コードではなく、単なるサンプルです)

質問、デルファイで begin/end の代わりに try/finally または try/except を使用すると、悪い習慣、コードの匂い、または欠点が存在すると見なされますか?

アップデート

ばかげたサンプル コードで申し訳ありませんが、try/finally と try/except を明確にするためだけに begin/end を置き換えるふりをしません。 try/finally または try/except の開始/終了は必要ありません。

次のコードになります：

常に「10 秒待っています...」というメッセージを出力し、10 秒間スリープして、もう一度実行しますか? finallyつまり、ループがcontinue-edの場合でも、句内のステートメントは実行されますか?

私はこのパターンを数回見ました：

そして、私は疑問に思っていました: ロールバックに catch を使用するよりもなぜこれが優れているのですか?

失敗時に変更を確実にロールバックする 2 つの方法の違いは何ですか?

次の方法を想定します。

returnステートメントの後でもfinallyブロックが実行されることを理解しています。戻り値を「オーバーライド」することもできます。しかし、私の質問は、メソッドはreturnステートメントの後で、または最後にロック解除されるのでしょうか？

すべて、これは単純なものです。finally実行せずにブロック内の戻り値をテストする方法はありますか

resultよりクリーンな方法はありますか？の変数を使用する必要がありますか？

注：これは、私が現在行っていることを行うための多くの作業ではないことを認識しています。.NETの世界の複雑さに興味があります。

なぜステートメントが必要なfinallyのかわかりません。try...except...finally私の意見では、このコードブロック

を使用してこれと同じfinallyです：

私は何かが足りないのですか？

重複の可能性:
else の目的と最後に例外処理で

ステートメントにfinally条項が存在する理由を理解したいと思います。try/except私はそれが何をするかを理解していますが、それが言語の場所に値する場合、明らかに何かが欠けています。finally具体的には、節をフィールドに書くことと、try/exceptステートメントの外に書くことの違いは何ですか?

重複の可能性:
finally ブロックで例外をスローする

• catch ブロックは、try ブロックで例外がスローされた場合にのみ実行されます。

• 例外がスローされたかどうかにかかわらず、finally ブロックは常に try(-catch) ブロックの後に実行されます。

私の質問は、それを処理する方法よりも、最終ブロックで例外が発生した場合です?????

コンソール アプリケーション内で何らかの理由で、finally ブロックを実行できません。finally ブロックがどのように機能するかをテストするためにこのコードを書いていたので、非常に簡単です。

最初はここで説明した問題がありましたが、Visual Studio の外でプログラムを実行しようとすると、「プログラムが応答を停止しました」というエラーが発生しました。

だから私はtry/finallyブロックを持っています。finallyブロックでいくつかのメソッドを実行する必要があります。ただし、これらのメソッドはそれぞれ例外をスローする可能性があります。ネストされたfinallyブロックなしで、これらすべてのメソッドが呼び出される（または試行される）ことを保証する方法はありますか？

これは私が今していることです、それはかなり醜いです：

これを行うためのよりエレガントな方法はありますか？