問題タブ [try-finally]

重複の可能性:
コードはリダイレクト後に最終的に実行されますか?

こんにちは、

try/finally ブロック内で EndResponse を true/false に設定して Response.Redirect() を呼び出すとどうなりますか? 最後に呼ばれますか？

サンプルとして次のコードを取ります。

セクションでエラーが発生した場合、// do something作成されたTSomeObjectは解放されず、Screen.Cursorは、これらの行に到達する前にコードが壊れていたため、砂時計としてスタックしたままになりますか？

誤解しない限り、次のようなエラーの発生に対処するために、例外ステートメントを配置する必要があります。

今、私が本当に愚かなことをしているのでない限り、Finallyブロックとafter、およびExceptionブロックに同じコードを2回含める理由はないはずです。

基本的に、私が投稿した最初のサンプルに似た手順がある場合があります。エラーが発生した場合、カーソルは砂時計として動かなくなります。Exceptionハンドラーを追加すると役立ちますが、それを行うには汚い方法のようです。FinallyからExceptionの部分にコピーアンドペーストする醜いコードは言うまでもなく、基本的にFinallyブロックを無視します。

私はまだDelphiを非常に学んでいるので、これが簡単な質問/回答であると思われる場合はお詫びします。

ステートメントを処理し、オブジェクトを正しく解放し、エラーなどをキャプチャするために、コードをどのように正しく記述する必要がありますか？

誰かがtryfinallyを使用してデータベース接続（およびエラー）を処理する方法を教えてもらえますか？ベストプラクティスは何でしょうか？いろいろなスタイルを見てきましたが、どうしたらいいのかしら。テーブルのオープニングはTRYブロックに入れるべきですか、それともメインの接続文字列だけに入れるべきですか？私は通常自分のデータベース（絶対データベース、アクセス..）をexeフォルダーに置くので、これに対する最善のアプローチについて疑問に思っていました...または最初に次のようなファイルを確認してください...

???

スケジュールされたタスクとして実行するコンソール アプリを作成していますが、閉じるボタンを使用して閉じると、実行中のコードの finally ブロックが実行されないようです。次の非常に単純なコンソール アプリを使用して、この動作を再現しようとしました。

デバッガーを実行すると、これは行のブレークポイントにヒットしませんConsole.WriteLine。この単純なテストが意図したとおりに機能するかどうか、またはなぜこのテストまたは本番コードで finally ブロックが実行されないように見えるかはわかりません。

私は、finally ブロックは常に実行されると考えていました (それがブロックの要点ではありませんか?)。ここで何が起こっているのですか？

私は、リモート オブジェクト (クローンを操作するために複製できないオブジェクト) の変更を命令するコードの一部を操作している状況に遭遇しました。新しい状態にして、一連の反対のコマンドで行ったすべての変更を元に戻します。問題は、これらすべての変更の途中でエラーが発生した場合、これまでに行ったすべての変更をロールバックできるようにしたいということです。

私の頭に浮かんだ最適な解決策は、Python の try-finally ワークフローですが、コマンドのシーケンスが長い場合はかなり問題になります。

このように、必要なコマンドが増えるほど、インデントとネストが深くなり、コードが読みにくくなります。コマンドごとにロールバックアクションをプッシュするスタックを維持するなど、他の解決策をいくつか検討しましたが、これはかなり複雑になる可能性があり、バインドされたメソッドをスタックにプッシュするのは嫌いです。また、実行するアクションごとにカウンターをインクリメントすることも検討し、最終的にカウンターに応じて必要なロールバックの種類を決定しますが、そのようなコードの保守性は苦痛になります.

「トランザクション」と「ロールバック」の検索で得たほとんどのヒットはDB関連であり、より一般的な種類のコードにはあまり適合しませんでした.この残虐行為を体系的に平坦化する方法について誰かが良い考えを持っていますか?

ヒープ上で実行されるオブジェクトが、処理が完了したときに常に割り当て解除されるようにする方法を探しています。

スタックに割り当てられている場合、RAIIを使用して確実に処理できることを知っています-残念ながら、問題のオブジェクトはAPI関数を呼び出すことによって実際に作成されるため、これは（少なくとも直接的には）機能しません、ヒープ上に作成するオブジェクトへのポインターを返します。

したがって、概念的には、私がやりたいことは次のようなものです。

私が考えることができる唯一のことは、ある種のダミーのクリーンアップ クラスを作成し、スタック上にそのインスタンスを作成することです。

これを達成するためのより良い方法はありますか？それとも、これは受け入れられた解決策ですか？

ぶつかったテクニックについてアドバイスをお願いします。コード スニペットを見れば簡単に理解できますが、次の段落でもう少し詳しく説明します。

「コード サンドイッチ」イディオムの使用は、リソース管理を扱うのに一般的です。C++ の RAII イディオムに慣れていた私は、Java に切り替えたところ、例外セーフなリソース管理の結果、コードが深くネストされていることがわかりました。このコードでは、通常の制御フローを把握するのに非常に苦労しました。

どうやら ( Java データ アクセス: この Java データ アクセス コードのスタイルは良いのか、それとも最後に試行しすぎているのか?、Java io の醜い try-finally ブロックなど) 私は一人ではありません。

これに対処するために、さまざまな解決策を試しました。

1. プログラムの状態を明示的に維持します: resource1aquired, fileopened..., そして条件付きでクリーンアップします: if (resource1acquired) resource1.cleanup()... しかし、明示的な変数でプログラムの状態を複製することは避けます。ランタイムは状態を認識しており、私はそれを気にしたくありません。

2. ネストされたすべてのブロックを関数でラップ - 制御フローをたどるのがさらに難しくなり、非常に厄介な関数名になります: runResource1Acquired( r1 )、runFileOpened( r1, file )、 ...

そして最後に、コード サンドイッチに関するいくつかの研究論文に(概念的に) 裏付けられたイディオムにたどり着きました。

これの代わりに：

ヘルパー構成を使用すると、補正コードがオリジネーターのすぐ隣にある、より直線的な構成に到達する可能性があります。

ネストされたコードは線形になります。

私はうれしく思いました。例外的なパスがいくつあっても、制御フローは線形のままであり、クリーンアップ コードは視覚的に元のコードの隣に表示されます。その上、人為的に制限されたメソッドを必要としないため、closeQuietly柔軟性が向上します (つまり、CloseableオブジェクトだけでなくDisconnectable、Rollbackableその他のものも)。

しかし...

この手法については、他の場所で言及されていません。だからここに質問があります：

このテクニックは有効ですか？どのようなバグが見られますか?

どうもありがとう。

プログラムが終了する前にコードを実行したかったので、VSに編集するとProgram.csが次のように作成されたと思いました。

トリックspecial_shutdown_code()はできますが、メインフォームの右上隅にある[x]をクリックしても実行されません。私は戻って、印刷ステートメントを追加しました：

「Before」が印刷された唯一の出力でした。

私が読んだものから、Application.Run関数が返されるはずです。私は途方に暮れています。説明をいただければ幸いです。

これはC++/ CLR + C＃+ C混合プログラムですが、主要部分はC＃です。

同じ機能を実現する方法の提案ではなく、何が起こっていないのかについての説明を得たいと思っています。私はほとんどの場合これを回避することができますが、最もクリーンで理解しやすいように見え、それを行う正しい方法がまったく機能しないと私は混乱します。

最終的にブロック実行しますか？出口を通過した場合。？

またはを持たない言語でまたはをシミュレートする方法はありますか？try-finallytry-except

ランダムで予測できない例外が発生した場合は、クリーンアップが実行されていることを確認する必要があります。

例外がスローされないようにすることができます。そうすれば、クリーンアップコードが常に実行されると確信できますが、その場合は、は必要ありませんtry-finally/except。

この瞬間、私はtry-finallyLuaでを作成しようとしています。しかし、どのソリューションも他の言語でも機能すると思います。

しかし、私の人生では、言語インフラストラクチャによって提供される配管なしで例外を処理する方法を理解することはできません。

しかし、尋ねることを傷つけることはありません。