問題タブ [finally]

C++ は ' finally ' ブロックをサポートしていますか?

RAIIイディオムとは何ですか?

C++ の RAII イディオムとC# の「using」ステートメントの違いは何ですか?

finallyブロックの使い方が間違っていて、その目的の基本を理解していない疑いがあります...

この関数はcatchブロックを実行し、「エラー」を警告しますが、true を返します。false を返さないのはなぜですか?

finallyC ++にはないため、コードを例外安全にする場合は、代わりにRAIIデザインパターンを使用する必要があります。これを行う1つの方法は、次のようなローカルクラスのデストラクタを使用することです。

クリーンアップコードを2回記述する必要がないため、これは単純なソリューションよりも大きな利点です。

ローカルクラスソリューションの大きな欠点は、クリーンアップコードでローカル変数に直接アクセスできないことです。したがって、それらにアクセスする必要がある場合は、コードが大幅に肥大化します。

だから私の質問は：両方の利点を組み合わせた解決策はありますか？そのため、a）重複するコードを記述する必要がなく、b）task最後の例のように、クリーンアップコード内のローカル変数にアクセスできますが、そのようなコードの膨張はありません。

Bjarne Stroustrup は、彼のC++ Style and Technique FAQに書いています。

C++ は、ほとんど常により優れた代替手段をサポートしているため、「リソース取得は初期化」手法 (TC++PL3 セクション 14.4) です。基本的な考え方は、ローカル オブジェクトのデストラクタがリソースを解放するように、ローカル オブジェクトによってリソースを表すことです。そうすれば、プログラマーはリソースの解放を忘れることはありません。例えば：

システムでは、リソースごとに「リソース ハンドル」クラスが必要です。ただし、リソースを取得するたびに「finally」句を付ける必要はありません。実際のシステムでは、リソースの種類よりもはるかに多くのリソースの取得が行われるため、「リソースの取得は初期化です」という手法は、「最終的に」構成を使用するよりもコードが少なくて済みます。

Bjarne は、「常により良い」ではなく、「ほぼ常により良い」と書いていることに注意してください。さて、私の質問ですがfinally、C++ で代替コンストラクト (RAII) を使用するよりもコンストラクトの方が優れているのはどのような状況でしょうか?

これは、標準 C++ で Final のような動作を実装する良い方法ですか? (特別なポインタなし)

1. オブジェクトによって例外がスローされない -> NoException -> オブジェクトがクリーンアップされる
2. オブジェクトによってスローされた例外 -> 処理済み -> NoException -> オブジェクトのクリーンアップ
3. オブジェクトによってスローされた例外 -> スローされた -> 例外 -> オブジェクトがクリーンアップされた -> スローされた

最終的にJavaで実行されない可能性がある条件はありますか? ありがとう。

Is there an elegant way to handle exceptions that are thrown in finally block?

For example:

How do you avoid the try/catch in the finally block?

Javaを何年もやっているので、C++を追跡していません。最終的に、言語定義のC ++例外処理に句が追加されましたか？

Javaのtry/finalを模倣する好ましいイディオムはありますか？

また、JavaのThrowableクラスのように、C ++には、スローされる可能性のあるすべての例外に対する究極のスーパータイプがないことも気になります。

私は書くことができます：

補遺編集：

投票数が最も多かった、つまりデストラクタを使用してクリーンアップを行う回答を受け入れることになりました。もちろん、私自身のコメントから、私がそれに完全に同意しないことは明らかです。ただし、C ++はそれ自体であるため、私が念頭に置いているアプリケーションの取り組みでは、多かれ少なかれ、一般的なコミュニティの慣習に従うように努めます。テンプレートクラスを使用して、クラスデストラクタがまだないリソース（つまり、Cライブラリリソース）をラップし、デストラクタセマンティクスを付与します。

新しい補遺編集：

うーん、最終的には閉鎖機能ではなく、おそらく？ScopeGuardアプローチ（以下の回答の1つを参照）と組み合わせたクロージャーは、任意のアクションとクリーンアップコードの外部スコープコンテキストへのアクセスを使用してクリーンアップを実行する方法になります。クリーンアップは、リソースが開かれているときにクリーンアップブロックを提供するRubyプログラミングで見られるイディオム方式で実行できます。C ++ではクロージャ機能が検討されていませんか？

私はJava初心者で、次の典型的なJavaコードがあるかどうか疑問に思っていました

JVM は、finally ブロックが常に実行されることを保証しますか? 私がどこから来たのかを理解するために、NULL ポインターを逆参照し、その後実行するコードがない場合にクラッシュする可能性のある C/C++ プログラムに慣れています。

しかし、Java と GC/マネージ メモリ ビジネス全般を理解しているので、null ポインターの逆参照などはありません。 、またはありますか？たとえば、Pythonでは、通常、

そして、コードを通過せずにアプリが死ぬことは一度もありません。

もちろん、OS がなんらかの理由でプロセスを強制終了した場合 (またはプラグを抜くなど、何かがシステム全体を強制終了した場合)、Java にできることはあまりありません。また、PHP から、インタープリターが発生した後もまだそこにあったとしても、保護できないキャッチ不能なエラーを知っています (少なくとも、適切なメッセージを出力することができます)。

編集：わかりやすくするために（誰も誤解していませんでした）、最終的にバイパスされる可能性のあるコード内のものを探していたことを付け加えさせてください。System.exit を指すことは、なぜそのようなことをしたいのかわかりませんが、参考になりました。

JVMの終了はかなり明白な方法であり、私はそれを外的原因として数えます。JVM とアプリの実行中にスレッドが終了する可能性も覚えておく必要があることを指摘するメモは、非常に役に立ちました。

次の動作が少なくとも奇妙であることがわかりました。

句returnの中で使用すると、例外は消えます。finallyそれはバグですか？それはどこかに文書化されていますか？

しかし、本当の質問 (および私が正しいとマークする答え) は次のとおり
です。その奇妙な動作を許可する Python 開発者の理由は何ですか?