私が実際にstd::error_conditionとstd::error_categoryが必要かどうか疑問に思うようになったので、std::error_codeの仕組みを理解するために旅に出てきました。私はthisとthisのチュートリアルに実装しようとしていますが、作業量はかなり脆弱です（現在、このコードが重複するシンボルでリンクエラーを引き起こす理由を理解しようとしています）。本当にstd :: error_categoryとstd :: error_conditionが必要ですか？
は、それが簡単にstd::error_codeをサブクラス化するために、messageプロパティ&メソッドを追加してstd::error_codeは、エラーコードが定義されている列挙型と比較することは聞かせていませんか？私はstd::error_categoryと全くstd::error_conditionを必要とする理由を理解するのに苦労しています。
主な利点は、error_codeがライブラリからライブラリwiに渡すことができるコピー可能なタイプであることですダイナミックメモリの割り当てやテンプレート化が必要なため、非常に軽量で作業が容易です。
完全に自己完結型のプロジェクトを作成している場合、エラーコードとカテゴリは、自分のタイプを持つことができれば、複雑すぎるようです。
ただし、think-async.comをリンクしているため、他の人が使用するライブラリ（ASIOなど）を書くときに変化があります。ライブラリーにerror_codeインスタンスを受信させることができます。ライブラリーを使用しているコードについて何も知らなくても、きちんと効率的に渡すことができます。また、すべてのエラー処理関数をエラーにテンプレート化する必要があります。タイプ。
複数のエラーソースを扱う場合、エラーカテゴリは重要です。特定のエラーコードは、エラーの原因に基づいて2つの異なることを意味する可能性があるためです。
編集：最初のリンクでは、カテゴリは実際にシングルトンであることに注意してください。これは、軽量化を維持するサービスで行われます。これは、削除または変更されないことが保証されているオブジェクトへのポインタをコピーするのが安価で、メモリに安全で、スレッドセーフであるためです。
私は、 'std :: system_error'のような標準的な例外型を介してカスタムエラーコードを簡単に移すこともできると付け加えたいと思います。ライブラリを使用するクライアントコードは、カスタムエラーカテゴリについて何も知る必要はありません。彼らは 'std :: system_error'をキャッチし、' std :: error_code'の* generic *メソッドを呼び出すことで、ログファイルに書き込むことができます。エラー値、定義したエラーカテゴリの名前、エラーカテゴリで定義した文字列メッセージが表示されます。誰もがそれがどのコンテキストに属しているかを知りません "エラーコード123"を出力するだけでなく、はるかに優れています。 – zett42
C++でエラーを処理する方法はいくつかありますが、真実はありません。必要がない場合は、使用しないでください。 –