重複の可能性:
アサートまたは例外による契約テストによる設計?
アサートの代わりに例外を使用することを決定する際に従うべき経験則はありますか (またはその逆)。現在、実行時にユーザー側で発生すると思われるもの (ソケットまたはファイル エラーなど) の場合にのみスローします。私が使用する他のほとんどすべてはアサートします。
また、アサートをスローする場合、スローするのに適した標準オブジェクトは何ですか? 私の記憶が正しければ がありますがstd::logic_error、それは投げるのに適したオブジェクトではありませんか? 不足しているファイルまたは予期しない入力 (フロントエンド アプリではなくコマンド ラインからなど) に対して何をスローしますか?
私の経験則：
例外は、ランタイム エラー状態 (IO エラー、メモリ不足、データベース接続を取得できないなど) に使用されます。
アサーションはコーディング エラーに使用されます (このメソッドは null を受け入れませんが、開発者は null を渡しました)。
パブリック クラスを持つライブラリの場合は、パブリック メソッドで例外をスローします (そうするのが理にかなっているからです)。アサーションは、相手のミスではなく、あなたのミスをキャッチするために使用されます。
編集: null 値の例のため、これは完全に明確ではない場合があります。私のポイントは、絶対に発生してはならない条件、および本番コードに入れてはならない条件に対して（他の人が指摘したように）アサーションを使用することです。これらの条件は、単体テストまたは QA テスト中に絶対に失敗する必要があります。
起こり得ないことがわかっていることを主張します（つまり、それが起こった場合、それは無能であるというあなたの責任です）。
プログラムの通常の制御フローでは処理されない例外的な状況を発生させます。
私は、決して起こらないはずのことに対して assert を使用します。それが起こったとき、開発者は誤った仮定を再検討する必要があるようなものです。
私は他のすべてに例外を使用します。
再利用可能なコードでは、呼び出し元が問題を処理するか処理しないかを選択できるため、例外を好みます。アサートをキャッチして処理してみてください!
例外的な状況には例外を使用します。たとえば、メモリ不足の状況やネットワーク障害などです。
assert を使用して、特定の前提条件が満たされていることを確認します。たとえば、ポインターが NULL でないか、整数が特定の範囲内にある場合です。
アサートは、プログラムが可能な状態にあることを確認する手段です。関数が正の整数のみを返す必要があるときに -1 を返し、それを検証するアサートがある場合、プログラムは危険な状態になるため停止する必要があります。
原則として、以下から例外をスローします。
ここで、アサートを内部でのみ使用して、実装の間違いを見つけます。