例外の仕様が悪いのはなぜですか？

約10年以上前の学校に戻って、彼らは例外指定子の使用を教えていました。私のバックグラウンドは彼らの1人であるため、強制されない限り頑固にC ++を避けるトーバルディッシュCプログラマーなので、私は散発的にC ++になってしまい、私が教えられたので例外指定子を使用しています。

ただし、C ++プログラマの大半は、例外指定子に眉をひそめているようです。これらのようなさまざまなC ++の達人からの議論と議論を読みました。私の知る限り、それは次の3つに要約されます。

1. 例外指定子は、残りの言語と矛盾する型システムを使用します（「シャドウ型システム」）。
2. 例外指定子を持つ関数が、指定したもの以外の何かをスローする場合、プログラムは悪い、予期しない方法で終了します。
3. 例外指定子は、今後のC ++標準で削除される予定です。

ここで何かが足りないのですか、それともすべての理由ですか？

私自身の意見：

1）に関して：それで何。C ++はおそらく、構文的にはこれまでに作成された中で最も一貫性のないプログラミング言語です。マクロ、goto / labels、undefined- / unspecified- / implementation-defined動作の大群（hoard？）、不十分に定義された整数型、すべての暗黙的な型昇格規則、friend、autoなどの特別な場合のキーワードがあります。 、登録、明示...など。おそらく、C / C ++のすべての奇妙さについての厚手の本をいくつか書くことができます。それでは、なぜ人々はこの特定の矛盾に反応するのでしょうか。これは、言語の他の多くのより危険な機能と比較して、小さな欠陥です。

2）に関して：それは私自身の責任ではありませんか？C ++で致命的なバグを作成できる方法は他にもたくさんありますが、なぜこの特定のケースはさらに悪いのでしょうか？throw(int)Crash_t を記述してからスローする代わりに、関数がintへのポインターを返し、ワイルドで明示的な型キャストを行い、Crash_tへのポインターを返すと主張することもできます。C / C ++の精神は、ほとんどの責任をプログラマに任せることでした。

では、利点はどうですか？最も明白なのは、関数が指定したもの以外の型を明示的にスローしようとすると、コンパイラーがエラーを出すことです。これに関しては標準が明確だと思います（？）。バグが発生するのは、関数が他の関数を呼び出し、その関数が間違った型をスローした場合のみです。

決定論的な組み込みCプログラムの世界から来た私は、関数が私に投げかけるものを正確に知ることを最も確実に好むでしょう。それをサポートする言語に何かがあれば、それを使用してみませんか？選択肢は次のようです：

void func() throw(Egg_t);

そして

void func(); // This function throws an Egg_t

呼び出し元が2番目のケースでtry-catchを実装することを無視/忘れる可能性は大きいと思いますが、1番目のケースではそうではありません。

私が理解しているように、これら2つの形式のいずれかが突然別の種類の例外をスローすることにした場合、プログラムはクラッシュします。最初のケースでは、別の例外をスローすることが許可されていないため、2番目のケースでは、SpanishInquisition_tをスローすることを誰も期待していないため、その式は本来あるべき場所にキャッチされません。

後者の場合、プログラムの最高レベルで最後の手段としてcatch（...）を使用することは、プログラムクラッシュよりも優れているようには見えません。「ねえ、あなたのプログラムのどこかで、奇妙な未処理の例外がスローされました。 。 "。例外がスローされた場所から遠く離れると、プログラムを回復できません。できることは、プログラムを終了することだけです。

また、ユーザーの観点からは、OSから「プログラムが終了しました。アドレス0x12345のBlablabla」という悪意のあるメッセージボックス、またはプログラムから「未処理の例外：myclass」という悪意のあるメッセージボックスを受け取ったとしても、それほど気にすることはありませんでした。 func.something」。バグはまだそこにあります。

今後のC ++標準では、例外指定子を放棄する以外の選択肢はありません。しかし、私はむしろ、「彼の法王がそれを述べているので、そうである」というよりも、なぜ彼らが悪いのかという堅実な議論を聞きたいと思います。おそらく、私がリストしたものよりも多くの議論がありますか、それとも私が理解している以上のものがありますか？

例外仕様は弱く施行されており、したがって実際にはあまり達成されないため、また、UBを呼び出さずに終了（）できるようにランタイムが予期しない例外をチェックするように強制するため、悪いです。 、これはかなりのパフォーマンスを浪費する可能性があります。

そのため、要約すると、例外仕様は言語で実際にコードをより安全にするほど強く強制されておらず、指定どおりに実装するとパフォーマンスが大幅に低下しました。

誰もそれらを使用しない理由の1つは、主な仮定が間違っているためです。

「最も明らかな[利点]は、関数が指定したもの以外の型を明示的にスローしようとすると、コンパイラーがエラーを出すことです。」

struct foo {};
struct bar {};

struct test
{
    void baz() throw(foo)
    {
        throw bar();
    }
};

int main()
{
    test x;
    try { x.baz(); } catch(bar &b) {}
}

このプログラムは、エラーや警告なしでコンパイルされます。

さらに、例外が捕捉されたとしても、プログラムは終了します。

編集：あなたの質問のポイントに答えるために、キャッチ（...）（以上、キャッチ（STD :: exeption＆）またはその他の基底クラス、およびその後、キャッチ（...）は）そうでない場合でも、まだ便利です何が間違っていたのかを正確に知る。

ユーザーが「保存」のメニューボタンを押したとします。メニューボタンのハンドラーは、保存するアプリケーションを招待します。これは無数の理由で失敗する可能性があります。ファイルが消えたネットワークリソース上にあり、読み取り専用ファイルがあり、上書き保存できませんでした。しかし、ハンドラーは何かが失敗した理由を本当に気にしません。成功したか失敗したかのどちらかだけを考慮します。それが成功した場合、すべてが良いです。失敗した場合、ユーザーに通知できます。例外の正確な性質は無関係です。さらに、適切で例外に対して安全なコードを記述すると、そのようなエラーは、エラーを気にしないコードであっても、ダウンさせることなくシステム全体に伝播できることを意味します。これにより、システムの拡張が容易になります。たとえば、データベース接続を介して保存するようになりました。

Anders Hejlsbergとのこのインタビューは非常に有名です。その中で、彼は最初にC＃設計チームがチェック例外を破棄した理由を説明します。簡単に言えば、2つの主な理由があります。バージョン管理性とスケーラビリティです。

OPはC ++に焦点を当てているのに対し、HejlsbergはC＃について議論していますが、Hejlsbergが指摘する点はC ++にも完全に当てはまります。