C++のエラー処理は、単に「失敗を見つける方法」ではありません。
実際には、異常をどう表現するか、どう呼び出し元へ伝えるか、どう安全に後始末するか、そして必要ならどう復旧するかまで含めた設計の話です。
C++では、エラー処理の方法がひとつに決まっているわけではありません。
代表的な手法としては、戻り値で失敗を表す方法、例外を使う方法、エラーコードを返す方法、値の不在を型で表す方法、開発時の前提違反をアサートで検出する方法などがあります。
重要なのは、それぞれの手法に向いている場面が違うという点です。
戻り値でエラーを表す方法
もっとも基本的なのは、関数の戻り値で成功か失敗かを示す方法です。
このやり方は単純で理解しやすく、例外を使わない方針の環境でも扱いやすいという利点があります。
一方で、成功か失敗かしか表せないと、なぜ失敗したのかが分かりにくくなります。
また、呼び出し側が毎回結果を確認する必要があるため、チェック漏れが起きやすいという欠点もあります。
処理が増えると、正常系よりも失敗確認の記述ばかりが目立つようになることもあります。
そのため、単純な失敗通知には向いていますが、詳細なエラー情報が必要な場面では不十分になりやすいです。
エラーコードを返す方法
戻り値の代わりに、失敗理由を表す列挙値やエラーオブジェクトを返す方法もあります。
これは、成功・失敗だけでなく「何が原因で失敗したのか」を明示しやすいのが利点です。
この方式は、失敗がある程度日常的に起こりうる処理や、低レイヤーの処理、あるいは例外を避けたいコードベースでよく使われます。
とくにシステム寄りの処理やライブラリ境界では、例外よりエラーコードのほうが扱いやすいことがあります。
ただし、これも呼び出し側が明示的に確認しなければ意味がありません。
設計が統一されていないと、ある関数は真偽値、別の関数は整数、さらに別の関数は独自コードを返す、といったばらつきが発生し、API全体が使いにくくなります。
結果とエラー情報をまとめて返す考え方
成功時の値と失敗時の情報をひとつの型でまとめて扱う設計もあります。
これは、成功なら結果を持ち、失敗ならエラー情報を持つ、という形で表現する考え方です。
この方式の利点は、単なる真偽値より表現力が高く、例外ほど制御フローが飛ばないことです。
呼び出し側に失敗処理を明示的に書かせたい場合にも向いています。
近年のC++では、この考え方を型として表しやすくする方向が強くなっています。
C++23では std::expected が標準化され、成功値またはエラー値を型で表現できるようになりました。
ただし、実際に使えるかどうかは処理系の対応状況に依存します。
この方向性は、例外を避けたいが、単純な真偽値では情報が足りない、という場面で特に有効です。
例外処理
C++における代表的なエラー処理のひとつが例外です。
例外は、通常の戻り値とは別の経路で失敗を上位へ伝える仕組みです。
例外の強みは、正常系の処理と異常系の処理を分離しやすい点にあります。
関数が本来返したい値は戻り値として扱い、失敗時だけ例外で通知できます。
また、関数呼び出しが深くネストしていても、その場で細かくエラー処理を書かず、上位のまとまった場所で捕捉できるという利点があります。
一方で、制御の流れがコード上で見えにくくなることがあります。
呼び出し側がどこで例外を捕まえるのか、途中でどんな後始末が必要かを意識しないと、不具合の原因になりやすいです。
そのため、便利だからといって何にでも使うのではなく、「例外で表すべき失敗かどうか」を考えて使う必要があります。
例外が向いている場面
例外が向いているのは、通常の処理では起きない失敗や、その場で簡単に回復しにくい失敗です。
たとえば、設定ファイルが壊れている、必須リソースが取得できない、コンストラクタでオブジェクトを正しく初期化できない、といった場面では例外が自然です。
特にコンストラクタは戻り値を返せないため、オブジェクトの生成に失敗したことを自然に表す方法として例外はよく使われます。
C++では「正しく初期化できないなら、そのオブジェクトは作られない」という設計が一般的だからです。
ただし、これが唯一の方法というわけではありません。
例外を避けたい設計では、コンストラクタを直接使わせず、別の生成関数で結果型や期待値型を返す方法もあります。
例外が向いていない場面
例外が向いていないのは、失敗が普通に起こる入力検証や、頻繁に発生しうる通常分岐です。
たとえば、ユーザーが入力フォームに誤った値を入れる、検索して見つからない、条件に合うデータが存在しない、といった状況は、必ずしも異常とは言えません。
こうしたケースでは、例外よりも戻り値や結果型、あるいは値の有無を表す型で処理したほうが自然です。
重要なのは「失敗したかどうか」だけでなく、それが本当に“異常”なのか、それとも単なる想定内の結果なのかを区別することです。
標準の例外型について
C++標準ライブラリには、代表的な例外型がいくつか用意されています。
たとえば、引数が不正なときに使われるもの、範囲外アクセスを表すもの、実行時の失敗を表すものなどがあります。
ただし、これらの使い分けは教科書的には整理できますが、実務では必ずしも厳密ではありません。
たとえば logic_error 系は「前提条件違反」や「使い方の誤り」を表す意図が強く、runtime_error 系は外部要因や実行時にしか分からない失敗に向くと考えられますが、現場ではそこまで厳密に分けられていないこともあります。
そのため、例外型の分類にこだわりすぎるよりも、「呼び出し側にどういう意味で伝えたいか」「メッセージに十分な文脈があるか」を重視したほうが実用的です。
独自例外型
標準の例外型だけでは意味が足りない場合、独自の例外型を定義することもあります。
これは、たとえばファイルオープン失敗、設定読込失敗、通信失敗などを型として区別したいときに有効です。
独自例外の利点は、例外の種類そのもので失敗の意味を表せることです。呼び出し側も型で分類しやすくなります。
ただし、近年は必ずしも独自例外型を大量に作るのが正解というわけでもありません。
実務では、例外型はシンプルに保ちつつ、メッセージやログに文脈を十分に載せる設計のほうが扱いやすいこともあります。
例外を再送出するときの注意
例外を捕まえたあと、そのまま上位に投げ直したい場面があります。
このときは、現在処理中の元の例外をそのまま再送出する書き方を使うのが基本です。
捕捉した例外オブジェクトをあらためて投げる形にすると、基底型で受けていた場合に元の派生型情報が失われることがあります。
つまり、元の例外の種類や詳細が消えてしまう可能性があります。
そのため、「少しログを取ってからそのまま上へ渡す」という場面では、元の例外を保ったまま再送出する書き方を使うのが原則です。
例外は値で投げ、参照で受ける
C++では、例外は通常オブジェクトとして投げられ、受け取る側では参照で受けるのが基本です。
これは不要なコピーを避けるためでもあり、型情報を保つためでもあります。
特に受け取り側では、基底型の定数参照で受けることがよく行われます。
これにより、多くの標準例外や独自例外をまとめて扱いやすくなります。
catch (...) の扱い
あらゆる例外を受け取る書き方もあります。
これは、スレッドの入口やプログラム全体の最上位など、「ここより上に例外を出したくない」という境界で安全網として使うと有効です。
ただし、この方法では例外の型を直接扱えないため、細かい復旧処理には向きません。
何が起きたのか分からないまま握りつぶしてしまうと、デバッグも運用も非常に困難になります。
したがって、最上位でログを残して終了させる、あるいは必要に応じて再送出する、といった用途には向いていますが、中途半端な場所で安易に使うべきではありません。
RAIIの重要性
C++のエラー処理で非常に重要なのが RAII です。
これは、リソースの取得と解放をオブジェクトの寿命に結びつける考え方です。
C++では、例外が発生すると処理が途中で飛ぶことがあります。
このとき、手動で解放しなければならないメモリやファイル、ロック、ソケットなどを持っていると、後始末が漏れてリソースリークや不整合の原因になります。
RAIIを使えば、オブジェクトの寿命が終わるタイミングで自動的に解放処理が走るため、例外が起きても後始末しやすくなります。
C++で安全なエラー処理を書くうえでは、例外そのものよりも、例外が起きても状態を壊さない設計のほうが本質的に重要です。
例外安全性
C++では、例外が発生してもプログラムの状態が壊れないことを重視します。
これを例外安全性と呼びます。
一般には、例外が起きても最低限オブジェクトが壊れずリソースリークもしないこと、さらに理想的には「成功するか、何も起こらないか」のどちらかになることが望まれます。
もっと厳しい条件として、例外をまったく外へ出さない保証が求められることもあります。
この考え方は、単に try と catch の書き方を覚えるだけでは身につきません。
オブジェクトの状態変更の順序、所有権の設計、途中失敗時の巻き戻しを意識した設計が必要です。
noexcept について
C++には、その関数が例外を外へ出さないことを表す仕組みがあります。
これが noexcept です。
noexcept が付いた関数から例外が外へ出ると、通常はプログラムが終了する方向に進みます。
そのため、「付けたほうが良さそうだから付ける」という使い方は危険です。
本当に例外を外へ出さない設計になっている関数だけに使うべきです。
一方で、ムーブ操作などでは noexcept が重要になることがあります。
標準コンテナは、要素型のムーブが安全に行えると分かっていると、より効率的な内部処理を選べることがあるためです。
デストラクタと例外
デストラクタから例外を外へ出す設計は、原則として避けるべきです。
デストラクタは後始末のために呼ばれるものですが、ここでさらに例外が外へ出ると、プログラム終了の原因になりやすくなります。
とくに別の例外処理中であれば、非常に危険です。
そのため、失敗しうる終了処理がある場合は、デストラクタに押し込めるのではなく、明示的な終了処理関数を別に用意するほうが安全です。
デストラクタは、できるだけ失敗しない後始末に専念させるべきです。
assert と例外の違い
assert は、主に開発時に「ここは必ずこうであるはずだ」という前提を検証するための仕組みです。
つまり、外部からの通常の失敗を処理するものではなく、プログラム内部の不変条件や前提条件の破れを見つけるためのものです。
重要なのは、assert は通常リリースビルドで無効化されることがある点です。
そのため、ユーザー入力やファイル入力のような実行時検証に使うべきではありません。
そうした検証は、無効化されても困らないものではないからです。
簡単に言えば、assert は「利用者の入力ミスを処理する仕組み」ではなく、「プログラマの想定違反を早期に発見する仕組み」です。
optional の位置づけ
C++では、値があるかもしれないし、ないかもしれない、という状態を型で表せます。
これはエラー処理に使われることもありますが、厳密には「失敗」専用ではなく、「値の不在」を表す仕組みです。
たとえば、検索して見つからなかった、設定値が未指定だった、条件に合う要素が存在しなかった、という場合には、必ずしも異常とは言えません。
こうしたケースで「結果がない」という事実だけを表したいなら、optional は非常に自然です。
ただし、なぜ失敗したのかという情報を伝えたい場合には向きません。
理由が必要な場面では、結果型や例外、エラーコードのほうが適しています。
std::error_code の考え方
C++では、例外を使わずに構造化されたエラー情報を扱う方法として std::error_code があります。
これはOS由来の失敗だけでなく、標準ライブラリや独自ライブラリのエラー表現にも使える仕組みです。
例外を使いたくない場面や、低レイヤーで失敗を明示的に伝えたい場面では有力です。
また、標準ライブラリの一部機能では、例外を投げる版と error_code を受け取る版の両方が用意されていることがあります。こうしたAPIでは、用途に応じて方針を選べます。
例外と戻り値、どちらを使うべきか
これはよく議論されるテーマですが、絶対的な正解はありません。
大切なのは、失敗の性質に合わせて選ぶことと、コードベース全体で方針を揃えることです。
失敗がまれで、上位でまとめて処理したいなら例外が向いています。
逆に、失敗が通常の分岐として頻繁に起こるなら、戻り値や結果型のほうが自然です。
また、低レイヤーでは明示的な失敗通知を好み、上位のアプリケーション層では例外でまとめる、といった設計もあります。
ただしこれは一般法則ではなく、プロジェクト方針によります。
重要なのは「どの層で何を使うか」が一貫していることです。
よくないエラー処理の典型
C++では、エラー処理そのものよりも、中途半端な運用が危険です。
たとえば、例外を捕まえたのに何もせず握りつぶしてしまうのはよくありません。
何が起きたか記録されず、不具合の追跡が難しくなります。
また、戻り値による失敗通知を返しているのに、呼び出し側が確認しないのも危険です。
失敗後の状態で処理が続くと、別の場所でより分かりにくいバグになります。
さらに、ある関数は例外、別の関数は真偽値、別の関数は特殊な整数値で失敗を表すといった混在も問題です。
利用者が毎回ルールを確認しなければならず、設計の一貫性が失われます。
実務で大切な設計方針
C++のエラー処理では、個々の文法知識よりも設計方針の統一が重要です。
まず、どの失敗が想定内で、どの失敗が異常なのかを分ける必要があります。
次に、その種類に応じて、戻り値、結果型、例外、アサートなどを使い分けます。
そして何より、リソース管理は必ず自動化するべきです。
生の new と delete、手動のファイル解放、手動のロック解放などに頼ると、例外経路で漏れやすくなります。
C++で安全なコードを書くなら、所有権と寿命を明確にし、後始末をオブジェクトに任せる設計が重要です。
また、エラーメッセージには十分な文脈を入れるべきです。
単に「失敗した」ではなく、どの処理で、何をしようとして、何が起きたのかが分かるようにすることで、調査と運用が大幅に楽になります。
まとめ
C++のエラー処理で大切なのは、単に try と catch を覚えることではありません。
本質は、異常をどう表現するか、どこで扱うか、失敗しても状態を壊さないか、そして設計全体で一貫しているかにあります。
戻り値やエラーコードは、失敗を明示的に扱いたいときに向いています。
例外は、通常経路と異常経路を分け、上位でまとめて扱いたいときに有効です。
optional は値がないことを軽く表したいときに便利で、expected 的な考え方は成功と失敗を型で整理したいときに強力です。
assert は開発時の前提確認向けであり、実行時の入力検証には向きません。
そして、どの方法を選ぶにしても、RAIIと例外安全性の考え方がC++では非常に重要です。
結局のところ、C++のエラー処理は「どの手法が最強か」を決める話ではなく、失敗の性質とコードベースの方針に合った手段を選び、全体で統一することが最も重要です。
以上、C++のエラー処理についてでした。
最後までお読みいただき、ありがとうございました。
