c++ - C++ 例外とエラー プロキシ

Question

私は「例外なし」キャンプの一員でしたが、宗教的にはそうではありません. 例外を使用することの支持者によって頻繁に展開される議論について質問があります。

したがって、C++ の例外に関する私の最大の (唯一の) 不満は、コードの予測不可能性です。コード (VIM で IDE を使用せずに) を見て、すべての場合にそれが何をするかを正確に確認できるようにしたいと考えています。例外を除いて、throw と catch は多くの論理層から離れている可能性があるため、ロジック フローは明確ではありません。

プロ例外応答の典型的な反論は次のとおりです。

ええ、でもそれは代替案ではありません。

仮想ハンドル MyXYZError() を持つ MyErrorProxy というクラスがあり、MyClass が XYZ エラーを受け取る可能性があることがわかっていて、それを多くの論理層から離れて処理したい場合は、MyErrorProxy へのポインターを渡します (これは mixin である可能性があります)。 、インターフェイス、または単に集中型のエラー処理クラス)? ポインタを渡したくないですか？よし、スレッドセーフなシングルトンにしよう。これにはさらに配管が必要ですが、明示的であり、ロジック フローを追跡するのは非常に簡単です。

それが私が長い間コーディングしてきた方法です。

ここで私の質問は次のとおりです。これを行うことの本当の欠点は何ですか? 私がいなくなってからずっとこのコードを見て、あなたがそれを保守しているとしたら、あなたは怒るでしょうか? このメカニズムの代わりに、try(s) と catch(es) を本当に好むと思いますか?またその理由は?

Answer 1

これはあまり良い考えではありません。エラーコードを渡すのは厄介な方法のように思えます。例外を使用したくない場合は、エラー コードを使用します。少なくともエラーコードがあれば、人々はあなたが何をしているのか理解できます。

別の言い方をすれば、人々が例外を避けているのを見るたびに、彼らはその使い方を本当に理解していないのだと思います。彼らはいつもtry/catchについて話しています。実際には、適切にコーディングされた例外の使用では、try/catch はほとんどありません。私が遭遇したほとんどのユースケースでは、例外はエラーメッセージをスタックに戻して終了できるようにするための単なる方法です。try/catch ブロックは 1 つだけで、メインにあります。

もちろん、私は終了しない長寿命のサーバーをコーディングしました。例外によって渡されたメッセージをログに記録し、同じメッセージをクライアントに返し、待機ループを続行します。

要するに、システムには try/catch ブロックがほとんどないはずです。それがわかると、例外のロジックフローが理解しやすくなります。実際、それはシステムに組み込まれています。