コンストラクターから例外をスローする必要がありますか?

コンストラクターからの例外のスロー: 設計上の考慮事項

ソフトウェア開発の領域では、コンストラクターから例外をスローすることの妥当性について議論が続いています。この質問はプログラミング愛好家の間で議論を引き起こし、同僚の最近の質問により、私たちはこのトピックを詳しく調べるようになりました。

設計の観点からコンストラクターから例外をスローすることは許容されますか?

以下の例に示すように、クラスが POSIX ミューテックスをカプセル化するシナリオを考えてみましょう。

class Mutex {
public:
  Mutex() {
    if (pthread_mutex_init(&mutex_, 0) != 0) {
      throw MutexInitException();
    }
  }
};

この例では、pthread_mutex_init への呼び出しが失敗すると、ミューテックス オブジェクトは使用できなくなります。例外をスローすると、オブジェクトが一貫性のない状態で作成されなくなり、将来の潜在的なエラーが防止されます。

標準プラクティスとメンバー関数のアプローチ

次のような議論があるかもしれません。例外をスローする代わりに、クラスには pthread_mutex_init 呼び出しの結果に基づいてブール値を返す初期化用のメンバー関数を含めることができます。このアプローチには利点もありますが、微妙な問題が発生します。これは、すべてのユーザーが初期化関数を呼び出すことを忘れないように依存しているため、見落とされ、未定義の動作が発生する可能性があります。 RAII 原則 (リソースの取得は初期化である) からの逸脱により、オブジェクトの意図した設計が損なわれる可能性があります。

結論

どちらのアプローチにも利点がありますが、コンストラクターから例外をスローすることには利点があります。が標準として登場しました。早期に失敗することで、不完全または一貫性のないオブジェクトの作成を防ぎ、さらなる操作が実行される前にオブジェクトの状態が有効であることを確認します。

以上がコンストラクターから例外をスローする必要がありますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。