C++ エラー対処法を完全解説！初心者でもわかるエラー処理の全手法と実践テクニック

C++でプログラムを書いていると、多くの場合、エラーに悩まされる場面がやってくる。
コンパイルエラーならまだわかりやすいけれど、実行時に突然クラッシュしたり、意図しない動作をしたりすると「いったいどこで何が起きているんだ？」と途方に暮れることがある。
C++のエラー対処法は一つではなく、状況によって使い分けが必要な点が、特に初心者にとってとっつきにくいポイントでもある。
この記事では、C++のエラー処理にどんな手法があるのか、それぞれの使いどころとメリット・デメリットを、具体的なコード例を交えながら丁寧に解説していく。

この記事でわかること

• C++で起こるエラーの種類と、それぞれへの基本的な対処の考え方
• 例外処理（try/catch/throw）の仕組みと、使うべき場面・避けるべき場面
• エラーコード・std::expected・アサーションなど、例外に頼らない対処法
• 現場で使えるエラー処理のベストプラクティスと、手法を選ぶ判断基準

C++のエラーとは何か？まず「種類」を整理しよう

エラー処理の話をする前に、そもそも「C++のエラーってどういう種類があるのか」を押さえておくと、対処法の選び方がぐっとわかりやすくなる。
エラーをひとくくりにしてしまうと、適切な手法を選べないまま迷子になってしまうことが多い。

コンパイルエラー・リンクエラー・実行時エラーの違い

C++のエラーは大きく分けると、コンパイルエラー・リンクエラー・実行時エラーの3種類に整理できる。
それぞれ発生するタイミングと原因が異なるため、対処のアプローチも変わってくる。

コンパイルエラーは、ソースコードをコンパイルする段階で検出されるエラーだ。
文法の間違い、型の不一致、未定義の変数や関数の参照などが代表的な原因になる。
コンパイラがエラーメッセージを出してくれるので、場所は特定しやすい。
ただし、C++のコンパイラエラーメッセージはテンプレートを使っていると非常に長くなることがあり、初心者には読み解くのが難しく感じることもある。

リンクエラーは、コンパイル自体は通ったものの、複数のオブジェクトファイルをつなぎ合わせる「リンク」の段階で発生するエラーだ。
関数の定義が見つからない「未解決の外部シンボル」がその典型例で、宣言だけして実装を書き忘れたときや、ライブラリのリンク設定が漏れているときに出やすい。

実行時エラーは、プログラムが動いている最中に発生するエラーだ。
ゼロ除算・配列の範囲外アクセス・NULL ポインタの参照解除など、コンパイル時には検出できない問題が実行中に表面化する。
これが一番厄介で、再現性が低い場合や、原因が特定しにくいケースもある。

論理エラーとランタイムエラーのさらなる分類

実行時エラーをもう少し掘り下げると、「論理エラー」と「ランタイムエラー」という区分も出てくる。
論理エラーは、プログラムがクラッシュするわけではないが、計算結果や処理結果が意図と違うという状態のことだ。
プログラムは動いているのに、出力される値がおかしい、というケースがこれに当たる。
ランタイムエラーは、実行中に例外やクラッシュとして表れる問題で、スタックオーバーフロー・メモリ不足・ファイルが見つからないといった状況が典型的だ。

エラー処理が必要な理由と基本の考え方

そもそもなぜエラー処理が重要なのかというと、エラーを放置したままにすると、プログラムが予期しない動作をしたり、データが壊れたり、最悪の場合クラッシュしてユーザーに迷惑をかけてしまうからだ。
C++は高速で柔軟な言語である一方、メモリ管理などを開発者自身が責任を持って行う部分が多い。
そのため、エラーの検出と対処を適切に実装することが、安全で信頼性の高いプログラムを作る上での基本中の基本になる。

重要なのは、「エラーが起きたときだけ考える」ではなく、「エラーが起きることを前提に設計する」という発想への転換だ。
C++のエラー処理手法は複数存在し、それぞれに向いている状況がある。
次のセクションからは、代表的な手法を一つずつ詳しく見ていこう。

C++の例外処理（try/catch/throw）の仕組みと使い方

C++でエラー対処といえば、まず思い浮かぶのが「例外処理」だろう。
try・catch・throwという3つのキーワードを組み合わせた仕組みで、エラーが起きた場所と、それを処理する場所を分離できるのが特徴だ。
ただし、例外処理は「万能の解決策」ではないという点もきちんと押さえておく必要がある。

try・catch・throwの基本構文

例外処理の基本は非常にシンプルだ。
例外が発生する可能性のある処理をtryブロックで囲み、例外が発生したときの処理をcatchブロックに書く。
そして例外を発生させたい場所ではthrowを使って例外オブジェクトを投げる。

コードのイメージとしてはこんな感じになる：

• try { 例外が起きるかもしれない処理 }
• catch(例外の型 変数名) { エラー時の処理 }
• エラーが起きた場所で throw 例外オブジェクト;

例えば、ゼロ除算が起きそうな処理を書くとする。
割る数が0のときに std::runtime_error を throw し、それを catch で受け取ってエラーメッセージを表示する、という流れになる。
catchブロックは複数並べることができ、異なる例外の型に応じて処理を分岐させることも可能だ。

標準例外クラスの種類と使いどころ

C++の標準ライブラリには、よく使われる例外クラスがあらかじめ用意されている。
これらは <stdexcept> ヘッダーをインクルードすることで使える。
代表的なものを挙げると：

• std::runtime_error：実行時に判明するエラー全般（ファイル読み込み失敗など）
• std::logic_error：プログラムのロジック上の誤り（不正な引数など）
• std::invalid_argument：引数が不正な値だった場合
• std::out_of_range：範囲外アクセスが起きた場合
• std::bad_alloc：メモリ確保に失敗した場合

自分でカスタム例外クラスを作ることも一般的だ。
std::exception を継承し、what() メソッドをオーバーライドすることで、独自のエラーメッセージを持つ例外クラスを定義できる。
大規模なプロジェクトでは、エラーの種類ごとにカスタム例外クラスを用意しておくと、catch で細かく使い分けができて管理しやすくなる。

例外処理のメリットとデメリット

例外処理の最大のメリットは、エラーの発生場所と処理場所を完全に分離できる点にある。
深くネストした関数の中でエラーが起きたとき、戻り値でエラーをいちいち返しながら上位関数へ伝えていく必要がなく、例外を throw すれば適切な catch がある場所まで自動的に制御が移動する。
これにより、本来の処理ロジックがエラー処理コードで汚染されにくくなる。

一方でデメリットもある。
まず、例外処理はパフォーマンスコストが無視できない場面がある。
例外が実際に投げられると、スタックの巻き戻しが発生し、オーバーヘッドが生まれる。
組み込みシステムやリアルタイム処理が求められる環境では、例外処理を禁止しているプロジェクトも少なくない。
また、例外安全性を保つためのコード設計が必要になり、慣れていないと RAII（Resource Acquisition Is Initialization）の理解なしには適切に書くのが難しい。

さらに見落とされがちな注意点として、「例外を使えばエラー処理が充分」という考え方は危険だという点がある。
例外は局所的に処理できない状況を上位に伝えるための仕組みであり、すべてのエラーパターンをカバーできるわけではない。
例外が想定外の場所でキャッチされなかった場合は std::terminate が呼ばれてプログラムが終了してしまう。
例外処理は強力なツールだが、適切な設計と組み合わせて初めて力を発揮するものだ。

例外を使わないエラー処理：戻り値・エラーコード・std::expected

「例外処理は使うな」という意見を耳にしたことがある人もいるかもしれない。
実際、Googleのコーディングガイドラインをはじめ、例外禁止を方針としているプロジェクトは存在する。
では例外を使わない場合、どうやってエラーを処理すればいいのか。
ここでは代表的な代替手法を詳しく見ていく。

戻り値でエラーを返すアプローチ

最も古典的な方法が、関数の戻り値でエラーを表すやり方だ。
C言語から引き継がれた手法で、成功なら0、失敗なら負の値やエラーコードを返すパターンがこれに当たる。
C++でも依然としてよく使われており、特にパフォーマンスが重視される場面や、例外を使えない環境では今でも有力な選択肢だ。

この手法の問題点は、呼び出し側が戻り値のチェックをサボりやすいこと。
関数を呼び出した後に if 文でエラーチェックをする処理が積み重なると、コードが縦に長くなりやすく、本来の処理ロジックが埋もれてしまう。
また、関数が本来返したい値とエラーコードを同時に返すことができないため、出力引数（ポインタや参照で結果を受け取る）を使う設計が必要になることもある。

errno や独自エラーコードを使うパターン

C標準ライブラリでは、グローバル変数 errno にエラー状態が書き込まれる仕組みがある。
C++でも使えるが、スレッドセーフの問題や、errnoを確認し忘れるといったミスが起きやすいため、大規模なC++プロジェクトでの採用は慎重に検討したほうがいい。
独自のエラーコード列挙型（enum class）を定義して返す方法のほうが、型安全で扱いやすいことが多い。

C++17の std::optional と C++23の std::expected

C++17 以降では、std::optional を使うことで「値があるかもしれないし、ないかもしれない」という状態を型として表現できるようになった。
処理が成功したときは値を返し、失敗したときは std::nullopt を返すシンプルな使い方ができる。
ただし、なぜ失敗したかの情報（エラーの理由）を伝えることができないのが弱点だ。

C++23 では std::expected が標準に追加されました。これは「成功したときの値」か「失敗したときのエラー情報」のどちらかを返せる型で、例外を使わずに「なぜ失敗したか」まで伝えられる点が大きな進歩だ。
Rust の Result 型に近い考え方で、関数型プログラミングのスタイルに馴染みがある人には特に直感的に使えるだろう。

std::expected の使い方のイメージとしては、成功時は expected<型, エラー型> に値を入れて返し、失敗時は unexpected でエラー情報を包んで返す。
呼び出し側では has_value() で成否を確認し、value() で値を、error() でエラー情報を取り出せる。
例外のオーバーヘッドなしに、エラー情報を型安全に扱えるのが最大の魅力だ。

Outcome ライブラリという選択肢

std::expected が標準化される前から、似たようなアプローチを提供していたサードパーティライブラリとして Outcome がある。
std::expected の概念を先取りしたようなライブラリで、C++14/17 環境でも使えるため、古いコンパイラ環境では一つの選択肢になる。
ただし、現在は C++23 の std::expected が標準に入ったため、新規プロジェクトでは標準のものを使うほうが保守性は高い。

アサーションとデバッグ手法：開発中のエラー検出を強化する

エラー処理というと実行時の話ばかりに目が向きがちだが、開発中の「バグを早期に発見する」仕組みも非常に重要だ。
アサーションやデバッグ向けの手法を活用すると、問題が大きくなる前に食い止められることが多い。
ここでは、開発フェーズで特に役立つ手法を紹介する。

assert マクロの使い方と限界

C++で最もシンプルな事前条件チェックの手段が、<cassert> ヘッダーで提供されているassert マクロだ。
引数に渡した条件式が偽（false）だったとき、プログラムを即座に終了させてエラーメッセージを表示する。
「この値は絶対にゼロにならないはず」「このポインタはNULLであってはならない」といった前提条件の検証に使う。

assertの注意点として、リリースビルドでは NDEBUG マクロが定義されると assert が無効化されることがある。
これは意図した動作ではあるが、「デバッグ中は動いていたのにリリース後に落ちた」というケースの原因になることがある。
また、assert はプログラムを強制終了させるため、ユーザーへのエラー通知や後処理が必要な場面には向かない。
あくまで「開発中の前提違反を検出する」ための道具として使い、本番環境向けのエラー処理には別の手法を組み合わせるのが正しい使い方だ。

static_assert によるコンパイル時チェック

C++11 以降では、static_assert を使ってコンパイル時に条件をチェックできる。
テンプレートの型が期待する条件を満たしているか確認したり、特定のプラットフォームでのみコンパイルを許可したりする用途に使われる。
実行時エラーではなくコンパイルエラーとして問題を早期検出できるのが強みで、正しく使えば非常に強力な手法だ。

ストリームのエラーフラグ（failbit・badbit・eofbit）

C++の入出力ストリームには、エラー状態を管理するための内部フラグが用意されている。
ファイル読み込みや標準入力の処理を書くとき、このフラグを正しく確認することがエラー処理の基本になる。

• failbit：読み込みに失敗した（型変換エラー等）
• badbit：回復不能なストリームエラーが発生した
• eofbit：ファイルの末尾に達した

例えば、int型の変数に文字列を読み込もうとすると failbit が立つ。
badbit が立った場合は、ハードウェア障害など回復が難しい状態を示す。
これらのフラグを確認することで、「処理が成功したかどうか」を正確に把握できる。
fail()・bad()・eof()・good() といったメンバ関数でそれぞれのフラグ状態を確認できるので、ファイル処理を書くときは必ず組み合わせて使う習慣をつけておきたい。

デバッガの活用とログ出力の重要性

エラー処理の仕組みを作るだけでなく、実際に問題が起きたときに「何が起きているかを調べる」手段も整えておく必要がある。
GDB や Visual Studio のデバッガを使ったブレークポイントの設定・変数の監視は、実行時エラーの原因特定に欠かせないスキルだ。

また、ログ出力を適切に仕込んでおくことも重要だ。
std::cerr への出力や、spdlog などのログライブラリを使って、エラー発生時の状態を記録する仕組みを作っておくと、本番環境でのトラブル対応がぐっと楽になる。
「エラーが起きたときに何も情報が残っていない」という状況は、デバッグを極端に困難にするので、ログ設計は早めに考えておくのがおすすめだ。

C++エラー処理のベストプラクティスと手法の選び方

ここまで複数のエラー処理手法を紹介してきたが、「結局どれを使えばいいのか」という疑問が湧いてくる人も多いと思う。
答えは「状況によって使い分ける」なのだが、その判断基準をここでしっかり整理しておきたい。
現場で通用するベストプラクティスと、手法を選ぶときの考え方を解説する。

最新C++のガイドラインが示す方向性

Microsoft の公式ドキュメントや C++ Core Guidelines（C++の設計者である Bjarne Stroustrup と Herb Sutter が主導するガイドライン）では、論理エラーとランタイムエラーの両方に対して、例外を使うことが推奨されている。これは最新の C++ における標準的な方向性だ。
例外はエラーの伝播を自動化し、リソースの安全な解放を RAII と組み合わせることで実現しやすくなるからだ。

ただしこれは「例外だけ使えばいい」という意味ではない。
組み込み・リアルタイム・ゲームエンジンなど、例外が禁止または非推奨の分野では、std::expected やエラーコードベースの設計が現実的な選択肢になる。
プロジェクトのコーディング規約やターゲット環境を最優先で確認することが重要だ。

RAII パターンとエラー安全性の考え方

例外処理と切っても切り離せないのが RAII（Resource Acquisition Is Initialization）というパターンだ。
これは「リソースの取得はオブジェクトの初期化時に行い、解放はデストラクタで行う」という考え方で、例外が発生してスタックが巻き戻されてもデストラクタが確実に呼ばれることを利用して、メモリ・ファイルハンドル・ミューテックスなどのリソースリークを防ぐ。

std::unique_ptr や std::shared_ptr といったスマートポインタはまさに RAII の代表例で、例外が発生してもメモリが適切に解放される。
例外処理を使う場合は、生のポインタではなくスマートポインタを使う習慣をつけることで、多くのメモリ関連の問題を事前に防げる。

エラー処理手法を選ぶための判断フロー

実際の開発で手法を選ぶとき、以下のような判断の流れを参考にしてほしい。

• プロジェクトのコーディング規約で例外が禁止されている場合 → 戻り値・std::expected・std::optional を使う
• 組み込みやリアルタイム処理など、パフォーマンスが最優先の場合 → エラーコードや戻り値ベースを検討する
• 一般的なアプリケーション・ライブラリ開発で例外が使える場合 → ランタイムエラーには例外、軽量な失敗表現には std::optional/expected を使い分ける
• 開発中の前提条件チェックには assert を使い、本番環境向けには別の仕組みを用意する

例外とエラーコードのどちらが良いかは議論の分かれるところだが、大切なのは「プロジェクト内で一貫性を保つ」こと。
混在させると可読性が下がり、エラー処理の見落としが生まれやすくなる。
チームや環境に合わせて方針を決めたら、それを統一して守ることが長期的な品質向上につながる。

よくあるエラー処理のアンチパターン

最後に、よくある「やってはいけない」パターンをいくつか挙げておく。

• catch(…) で全例外を握りつぶすのは厳禁。エラーの原因がわからなくなり、デバッグが困難になる
• 例外のスローとキャッチを通常の制御フローとして使う設計は避ける。
  例外は「例外的な状況」のためのものだ
• エラーコードを返す関数で、呼び出し側がその戻り値を確認しない設計も問題になりやすい
• assert に副作用のある式を書くと、リリースビルドで動作が変わってしまうことがある

まとめ：C++のエラー対処法を使いこなすために

この記事のポイントをまとめます。

• C++のエラーにはコンパイルエラー・リンクエラー・実行時エラー（論理・ランタイム）があり、種類に応じた対処が必要
• 例外処理（try/catch/throw）はエラーの発生場所と処理場所を分離できる強力な仕組みだが、パフォーマンスコストと例外安全性の設計が必要
• 例外を使わない手法として、戻り値・エラーコード・std::optional・std::expected などがあり、それぞれ向いている状況が異なる
• 開発中の問題早期発見には assert・static_assert・デバッガ・ログ出力が有効
• 最新C++のガイドラインでは例外の使用が推奨されているが、環境・規約によっては例外禁止の場合もあり、プロジェクト内の一貫性が最も重要
• RAII パターンを理解・活用することで、例外発生時のリソースリークを防げる

C++のエラー対処法は、覚えることが多くて最初は圧倒される気持ちもわかる。
でも、「どんなエラーが起きうるか」を意識しながらコードを書く習慣が身についてくると、少しずつ怖くなくなってくる。
例外処理・std::expected・アサーション、それぞれの役割をざっくりでも理解しておくだけで、問題が起きたときの対応スピードがぐっと上がる。
完璧に全部覚えなくてもいい。
まずは今書いているコードに「この処理が失敗したらどうなるか？」という問いを持ちながら向き合ってみてほしい。
それだけで、エラーとの付き合い方は確実に変わっていくはずだ。