問題タブ [function-try-block]

プログラマーが関数tryブロックをいつ使用するのか疑問に思います。いつ役に立ちますか？

出力:( ideoneで）

編集：関数定義の構文が間違っていると思う人もいるかもしれませんが（構文が見慣れないため）、間違いではないと言わざるを得ません。それはfunction-try-blockと呼ばれます。C++標準の§8.4/1[dcl.fct.def]を参照してください。

try-catch私は最近、関数のためにこの構文に出くわしました。

どちらの構文も有効です。コーディングスタイル以外に、これらの構文に技術的な違いはありますか？構文の1つは、他の構文よりも優れていますか？

リンクhttp://gotw.ca/gotw/066.htmには、

教訓 #1: コンストラクター関数の try ブロック ハンドラーには、例外を変換するという 1 つの目的しかありません。(そして、ロギングやその他の副作用を行うためかもしれません。) それらは他の目的には役に立ちません。

一方http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.8

コンストラクターが例外をスローした場合、オブジェクトのデストラクターは実行されません。オブジェクトが元に戻す必要のある処理 (メモリの割り当て、ファイルのオープン、セマフォのロックなど) を既に行っている場合、この "元に戻す必要のある処理" は、オブジェクト内のデータ メンバーによって記憶されている必要があります。

これらの 2 つのステートメントは矛盾していませんか? 最初の 1 つの種類は、コンストラクター内の try キャッチがほとんど役に立たないことを意味しますが、2 番目の種類は、リソースを解放する必要があることを示しています。ここで何が欠けていますか？

重複の可能性:
関数の try ブロックが役立つのはいつですか?
関数の try-catch 構文の違い

このコードは、 class 内でオブジェクトintを構築しているときに例外をスローします。例外は通常のブロックによってキャッチされ、コードは次のように出力します。DogUseResourcesinttry-catch

UseResources()ここで、コンストラクターの定義を、function try block以下のように を使用するものに置き換えると、

出力は同じです

つまり、まったく同じ最終結果が得られます。

それでは、の目的は何function try blockですか？

Herb Sutter によると、以下のコードはコンパイルできません。このサイトhttp://www.gotw.ca/gotw/066.htmを参照してください。ここから、次のテキストを抽出しましたfunction-try-blocks。

いくつかの道徳に向けて

ちなみに、これは、コンストラクター function-try-block の唯一の (繰り返しのみの) 可能な使用法が、ベースまたはメンバー サブオブジェクトからスローされた例外を変換することであることも意味します。それがモラル #1 です。次に、モラル #2 は、デストラクタ関数の try ブロックは完全に有用であると述べています。

" - ちょっと待って！" 部屋の真ん中から誰かが割り込むのが聞こえます。「モラル #1 には同意しません。コンストラクター関数の try ブロックの別の用途、つまり、イニシャライザー リストまたはコンストラクター本体で割り当てられたリソースを解放することを考えることができます!」

申し訳ありません。結局のところ、コンストラクターの try-block のハンドラーに入ると、コンストラクター本体のローカル変数も既にスコープ外であり、基本サブオブジェクトまたはメンバー オブジェクトが存在しないことが保証されていることを覚えておいてください。彼らの名前を参照することさえできません。オブジェクトの一部が構築されていないか、構築された部分が既に破棄されています。したがって、クラスのベースまたはメンバーへの参照に依存するものをクリーンアップすることはできません (とにかく、それがベースおよびメンバーのデストラクタの目的ですよね?)。

この引用符を仮定すると、プロセスが句catに実行されるまでにオブジェクトがすでに破棄されているため、次のコードはコンパイルされません。catchしかし、少なくとも VSC2008 ではそうです。

私は C++ で単純なスレッド化されたサーバー アプリケーションを作成しています。つまり、libconfig++ を使用して構成ファイルを解析しています。libconfig はマルチスレッドをサポートしていないため、「サポート」を実現するために 2 つのラッパー クラスを使用しています。ポイントは、そのうちの1つが失敗することです：

main.cpp ファイルから呼び出すと、ひどく失敗します。

そしてそれは言います：

私は明らかに引数を渡しているので、これは奇妙char *です.

いつものように、どんな助けでも大歓迎です。

ジュリアン。

このメソッドの try ブロックには、3 つの異なる終了の可能性があります。ここにそれらの2つがあります。

1) try ステートメントのコードが失敗し、例外がスローされます。これは、新しい FileWriter ステートメントが原因で発生した IOException、または for ループ内の間違ったインデックス値が原因で発生した IndexOutOfBoundsException である可能性があります。

2) すべてが成功し、try ステートメントは正常に終了します。

ここで言及されていないが、発生する可能性のある3番目の可能性は何ですか?

関数 try ブロックは、関数本体の特別な形式です。たとえば、次のようになります。

主な目的は、基本クラスのコンストラクターによってスローされた例外をログに記録するために、コンストラクターで使用することです。ただし、通常の関数でも使用できます。

これにはいくつかの (かなり古い) 質問があり、通常の関数 (たとえばFunction try ブロックなど) ではなぜそれが必要なのか、コンストラクターでは必要ないのかという質問があります。ただし、私の質問は少し別の方向にあります。通常の try ブロックの代わりに通常の関数で問題なく使用できますか? たとえば、審美的な理由だけでしょうか。

私は C++ ライブラリ用の C インターフェイスを開発しており、例外をキャッチするために各インターフェイス関数を try ブロックでカプセル化する必要があります。したがって、各関数に追加の中括弧ブロックを避けたいと思います...

私の懸念を引き起こした 1 つのこと: https://stackoverflow.com/a/11535436/6695750の回答で、davka は 2000 年の記事を引用しています。関数試行ブロック。gcc 5.4.0 でテストしたところ、catch ブロックから問題なく値を返すことができました。これは標準ですか、それとも gcc の非標準拡張ですか?