`catch（…）{throw; } `悪い習慣ですか？

... 再スローせずにキャッチするのは本当に間違っていることに同意しますが、次のような構造を使用すると信じています。

try
{
  // Stuff
}
catch (...)
{
  // Some cleanup
  throw;
}

RAIIが適用されない場合に受け入れられます。（質問しないでください...私の会社の全員がオブジェクト指向プログラミングを好むわけではなく、RAIIはしばしば「役に立たない学校のもの」と見られています...）

私の同僚は、どの例外がスローされるかを常に知っておく必要があり、次のような構造を常に使用できると言っています。

try
{
  // Stuff
}
catch (exception_type1&)
{
  // Some cleanup
  throw;
}
catch (exception_type2&)
{
  // Some cleanup
  throw;
}
catch (exception_type3&)
{
  // Some cleanup
  throw;
}

これらの状況に関して、十分に認められた良い慣行はありますか？

私の同僚は、どの例外がスローされるかを常に知っておくべきだと言っています[...]

あなたの同僚は、私がそれを言うのは嫌いだと思いますが、明らかに汎用ライブラリに取り組んだことがありません。

例外の安全性を保証しながら、コピーコンストラクターが何をスローするかを知っているふりをするようなクラスでstd::vectorも、一体どのようにできますか？

呼び出し時に呼び出される側がコンパイル時に何をするかを常に知っていれば、ポリモーフィズムは役に立ちません！時々、全体の目標は、下位レベルで発生することを抽象化することであるため、具体的に何が起こっているのか知りたくない場合があります！

あなたが巻き込まれているように見えるのは、ケーキを持って食べようとする誰かの特定の地獄です。

RAIIと例外は、連動するように設計されています。RAIIは、あなたがしない手段である必要があり、多くの書き込みにcatch(...)クリーンアップを実行するステートメントを。もちろん、それは自動的に行われます。また、例外はRAIIオブジェクトを操作する唯一の方法です。コンストラクターは成功またはスロー（またはオブジェクトをエラー状態にするが、だれがそれを望むのか）しかできないためです。

catch文は、2つのいずれかの操作を行うことができますエラーまたは例外的な状況を扱う、またはクリーンアップ作業を行います。両方catchを実行することもありますが、これらの少なくとも1つを実行するためのすべてのステートメントが存在します。

catch(...)適切な例外処理を行うことができません。例外が何なのかわかりません。例外に関する情報を取得できません。特定のコードブロック内の何かによって例外がスローされたという事実以外の情報はまったくありません。このようなブロックでできる唯一の正当なことは、クリーンアップを行うことです。そして、それはクリーンアップの終わりに例外を再スローすることを意味します。

例外処理に関してRAIIが提供するのは、無料のクリーンアップです。すべてが適切にRAIIカプセル化されている場合、すべてが適切にクリーンアップされます。catchステートメントをクリーンアップする必要はもうありません。その場合、catch(...)ステートメントを記述する理由はありません。

だから私はそれcatch(...)がほとんど悪であることに同意するだろう... 暫定的に。

その規定はRAIIの適切な使用です。それなしでは、特定のクリーンアップを実行できる必要があります。それを回避することはありません。クリーンアップ作業を行える必要があります。例外をスローすると、コードが適切な状態になるようにする必要があります。そして、catch(...)ある重要なそうすることでツール。

片方をもう片方なしに持つことはできません。RAII も悪いと catch(...)も言えません。これらのうち少なくとも1つが必要です。そうでなければ、あなたは例外的に安全ではありません。

もちろん、catch(...)RAIIでさえも消去できない有効な、しかしまれな使い方が1つありexception_ptrます。それは、誰かに転送することです。通常、promise/futureまたは同様のインターフェースを介して。

私の同僚は、どの例外がスローされるかを常に知っておく必要があり、次のような構造を常に使用できると言っています。

あなたの同僚はバカです（またはひどく無知です）。これは、彼があなたに書くことを提案しているコピーアンドペーストコードの量のためにすぐに明らかになるはずです。これらの各catchステートメントのクリーンアップはまったく同じになります。可読性は言うまでもなく、メンテナンスの悪夢です。

つまり、これはRAII が解決するために作成された問題です（他の問題を解決しないわけではありません）。

この概念について私を混乱させるのは、ほとんどの人がRAIIが悪いと主張する方法に一般的に逆行しているということです。一般に、引数は「RAIIは、コンストラクターの失敗を通知するために例外を使用する必要があるため悪い。しかし、安全ではなく、catchすべてをクリーンアップするために多くのステートメントが必要になるため、例外をスローできない」。RAII はRAIIの欠如が引き起こす問題を解決するため、これは壊れた議論です。

おそらく、彼はRAIIに反対しています。なぜなら、それは詳細を隠すからです。デストラクタの呼び出しは、自動変数ではすぐには表示されません。したがって、暗黙的に呼び出されるコードを取得します。一部のプログラマーは本当にそれを嫌います。どうやら、彼らが3つのcatchステートメントを持っていると考えるポイントまでは、コピーアンドペーストコードですべて同じことを行うのが良い考えです。

本当に2つのコメント。1つ目は、理想的な世界では、どのような例外がスローされる可能性があるかを常に知っておく必要があるということです。しかし、もっと重要なことです。可能性のある例外のすべてを正確に知っていても、それはここで関連していますか？ catch (...)よりはるかに良い意図を表現catch ( std::exception const& )しても、すべての可能な例外から派生したとすると、 std::exception（理想的な世界の場合）。いくつかのcatchブロックの使用に関して、すべての例外に共通のベースがない場合：それは完全に難読化であり、メンテナンスの悪夢です。すべての動作が同一であることをどのように認識しますか？そして、それが意図でしたか？また、動作を変更する必要がある場合（バグ修正など）はどうなりますか？見逃すのはとても簡単です。

あなたの同僚はいくつかの良いアドバイスを混同していると思います-あなたはcatchそれらを再スローしない場合にのみ、ブロック内の既知の例外を処理すべきです。

これの意味は：

try
{
  // Stuff
}
catch (...)
{
  // General stuff
}

それは静かに非表示になりますので、不良である任意のエラーを。

しかしながら：

try
{
  // Stuff
}
catch (exception_type_we_can_handle&)
{
  // Deal with the known exception
}

大丈夫-何を扱っているかはわかっているので、呼び出し元のコードに公開する必要はありません。

同様に：

try
{
  // Stuff
}
catch (...)
{
  // Rollback transactions, log errors, etc
  throw;
}

一般的なエラーを処理するコードは、それらを引き起こすコードと一緒にすべきです。トランザクションのロールバックなどが必要であることを、呼び出し先に依存するよりも優れています。

いずれかの答えはいまたはいいえがなぜそうなのかの根拠を伴うべきです。

私がそのように教えられたという理由だけで間違っていると言うことは、盲目的な狂信です。

//Some cleanup; throwあなたの例のように同じことを数回書くのは間違っています。なぜならコードの重複であり、メンテナンスの負担になるからです。一度だけ書いたほうがいいです。

catch(...)を処理する方法を知っている例外のみを処理する必要があるため、すべての例外を黙らせるためにa を書くことは間違っています。

ただし、を再スローするcatch(...)と、例外を実際に処理していないため、後者の理論的根拠は適用されなくなります。したがって、これを推奨しない理由はありません。

実際、何の問題もなく機密機能にログインするためにこれを行ってきました。

void DoSomethingImportant()
{
    try
    {
        Log("Going to do something important");
        DoIt();
    }
    catch (std::exception &e)
    {
        Log("Error doing something important: %s", e.what());
        throw;
    }
    catch (...)
    {
        Log("Unexpected error doing something important");
        throw;
    }
    Log("Success doing something important");
}

私はここの投稿の雰囲気に概ね同意します。特定の例外をキャッチするパターンは本当に嫌いです。この構文はまだ初期段階にあり、冗長なコードにまだ対処できないと思います。

しかし、誰もがそれを言っているので、私はそれらを控えめに使用しているにもかかわらず、私はしばしば「catch（Exception e）」ステートメントの1つを見て、「くそー、私は電話したいというのも、後でアクセスするときに、意図が何であり、クライアントが一目で何をスローする可能性があるかを知るのはいいことだからです。

私は「常にxを使用する」という態度を正当化するわけではありません。それらをリストするのを見るのは実にいいことだと言っているだけで、だからこそ「正しい」方法だと思う人もいるでしょう。