プログラミングをしていて「throw」というキーワードを見かけたけれど、何をしているのか、どんな場面で使えばいいのか意外とわからない、そんな方のための記事です。C#において例外処理は非常に重要な概念であり、throwを正しく使うことは信頼性の高いコードを書くうえで欠かせません。この記事では、throwの基本的な意味から応用、そして例外処理の流れまで、実用的なサンプルと最新仕様に基づいて説明します。読み終えた頃には、「C# throwとは 使い方」が腑に落ちるはずです。
目次
C# throwとは 使い方
この見出しでは、「C# throwとは 使い方」のキーワードをすべて含め、throwとは何か、基本的な使い方を明らかにします。throwはC#で例外を発生させるためのキーワードで、プログラム実行中に問題が起きたことを通知し、処理を例外ハンドラに移す仕組みです。正しく使えば、安全性と可読性の高いコードになります。
throwの定義と基本動作
throwは例外オブジェクトを生成し、それを現在のスコープ外へ伝播させるために使います。例外オブジェクトはSystem.Exceptionクラスまたはその派生クラスのインスタンスでなければなりません。throw new Exception(“エラーメッセージ”) のように新しい例外を作ることもできますし、catchブロック内で元の例外を再スローするために単に throw と記述することもあります。throw文が実行されると、以降の行は実行されず、例外処理の対象に制御が移ります。
例外を発生させる（throw new）
例外を発生させる典型的な方法が throw new ExceptionType(メッセージ) です。開発者はパラメータの不正値や状態が不適切なときに独自例外を投げて呼び出し元に問題を通知できます。既存の例外クラス（ArgumentNullException、InvalidOperationExceptionなど）を使うか、またはExceptionを継承してカスタム例外を定義することができます。この方法は問題発生時の原因を詳しく伝えることができ、デバッグが容易になります。
例外を再スローする（catch内からのthrowとthrow exの違い）
catchブロックで例外を捕捉した後、例外を再度投げたいときがあります。ここで throw と throw ex の間には大きな違いがあります。単に throw を使うと元のスタックトレースが保持されますが、throw ex のように例外オブジェクトを指定するとスタックトレースがその再スロー地点から新しくなってしまい、エラーの発生元がわかりにくくなります。スタックトレースを正確に残したい場面では throw を用いることが推奨されます。
C#の最新仕様におけるthrowの拡張：throw式
C#7以降、throwを式（expression）として使えるようになりました。この拡張により、null合併演算子（??）や条件演算子（?:）、式本体のプロパティやラムダ式の中で throw を直接使えるようになっています。例えば、プロパティのsetterで value ?? throw new ArgumentNullException(…) のように、値がnullのとき例外を即発生させる記述が可能です。この構文拡張はコードを簡潔かつ明快にし、意図しないnull参照などの防止に役立ちます。
例外処理の流れ：try, catch, finallyを含めた全体像
ここでは、throwを含む例外処理がプログラム中でどのように流れるかを、try, catch, finallyを使った典型的なパターンを通じて説明します。この流れを理解することで、例外が発生する場面、捕捉される場面、そして最終的に処理されるまでの道筋が明確になります。
tryブロックで例外を発生させる箇所
tryブロック内には例外が発生する可能性のある処理を置きます。ファイル操作、データベースアクセス、null参照などが典型例です。throw new を使って明示的に例外を発生させることもここで行います。tryブロックを出た時点でキャッチ可能な例外は catch ブロックへ渡されます。実行時システムがこの例外の型と一致する catch を探します。
catchブロックでの処理と再スロー
catch ブロックでは受け取った例外を処理します。ログ記録、状態の修正、エラー応答の生成などが含まれることが多いです。そして、必要に応じて例外を再スローすることがあります。このとき、throw 単体を使うと元の例外情報が保たれますが、throw ex のように指定してしまうとスタックトレースが上書きされるため注意が必要です。
finallyブロックでの後処理
finally ブロックは例外の発生・捕捉を問わず実行されます。リソースの解放、ストリームのクローズ、データベース接続の終了などをここで行います。例外が throw された後、catch を通過したあと、最終的に finally の処理が行われてから例外が呼び出し元に伝播することもあります。この流れを意識することで、例外発生時にもリソースリークなどが起こらない設計が可能になります。
実践サンプル：C# throwの使い方を例で理解する
この見出しでは、具体的なコード例を複数示して、C#でthrowをどのように使うかを実践的に理解できるようにします。基本的なthrow newからthrow式やカスタム例外までを含めます。
基本的な例：throw newを使った例外発生
次のようなコードを考えてみましょう。ファイルを読み込むメソッドにおいて、ファイルが存在しない場合に例外を投げる実装です。
public void ReadFile(string path)
{
if(path == null)
{
throw new ArgumentNullException(nameof(path), "パスがnullです");
}
if(!File.Exists(path))
{
throw new FileNotFoundException("ファイルが見つかりません", path);
}
// ファイル読み込み処理...
}このようにthrow newを使うことで、想定外の状況を呼び出し元に明示的に知らせることができます。
throw式を使ったプロパティや引数の検証
C#7以降、プロパティのsetterやメソッド引数で null をチェックして throw 式を使うことができます。例えば、次のように書けます。
public string Name
{
get => name;
set => name = value ?? throw new ArgumentNullException(nameof(value), "Nameにnullを設定できません");
}また、メソッド引数の検証にも同様の構文を使うことで、コードを短く明確にできます。
catchでの再スローとthrow exの落とし穴
catchブロックで例外を処理した後、再スローが必要な場合、throw と throw ex の違いを理解することが重要です。
try
{
// 処理...
} catch(Exception ex)
{
// ログ記録などの処理
throw; // スタックトレースを保つ再スロー
}一方、
catch(Exception ex)
{
// ここで ex を使って新しい例外メッセージを追加したいと思っても、throw ex では元のスタック情報が失われます。
throw ex; // スタックトレースがリセットされてしまう
}このように、throw ex は内部情報が欠落しがちなので、再スローには throw のみを使うことが望ましいです。
注意点とベストプラクティス：安全・保守性の高いthrowの使い方
throwを使う上で、コードの信頼性や将来の保守性を高めるためのポイントがあります。このセクションではよくある落とし穴と、それを避けるコツを最新の仕様に照らして紹介します。
例外の種類を使い分ける
System.Exception直下の基本例外をむやみに使うのは避けること。ArgumentNullException、ArgumentOutOfRangeException、InvalidOperationExceptionなど、状況に応じた適切な例外クラスを使うことで、呼び出し側が例外の意味を理解しやすくなります。カスタム例外を作るときは、少なくともメッセージ、内部例外（InnerException）を扱えるように設計することが大事です。
スタックトレースを保つための再スロー方法
catchブロックで例外を再スローする際は前述のとおり throw を使って元のスタックトレースを保持すること。throw ex を使うと例外の起点がcatch内に見えてしまい、デバッグ難易度が上がります。特に大規模プロジェクトやログ収集システムのある環境では、この小さな違いが後からの原因追究を大きく左右します。
null合併演算子（??）などでthrowを組み込む構文の活用
throw式を使えば、null合併演算子や条件演算子、プロパティアクセサなどの短いコード内で例外発生を明示できます。これにより、if文を使った冗長なチェックを減らし、可読性を向上できます。ただし、過度に使うと構文が複雑になることもあるため、意図がわかりやすくなる範囲に留めることが肝要です。
比較：throw vs throw ex の違いをサンプルで見比べる
この見出しでは、具体例で throw と throw ex の違いを比較し、どのような情報の差が生じるかを確認します。技術的には小さな差ですが、実際のデバッグやエラー対応での影響は大きいです。
サンプルコードでの振る舞い比較
以下のような例を考えます：
try
{
SomeMethod();
} catch(Exception ex)
{
Log(ex);
throw; // A
}
この A は元の例外発生場所のスタックトレースをそのまま保持します。
一方：
try
{
SomeMethod();
} catch(Exception ex)
{
Log(ex);
throw ex; // B
}この B は例外が throw ex の行から発生したようにスタックトレースが書き換えられるため、最初の発生場所を特定しにくくなります。
表で整理：throw/throw ex よくあるパターンとの比較
以下の表で、throw と throw ex の特徴を整理します。
| 特徴 | throw | throw ex |
|---|---|---|
| スタックトレースの保持 | 元の例外発生箇所を保持 | 再スロー場所から新スタックトレースが生成される |
| 主に使う場面 | catch内で例外をそのまま伝えたいとき | 例外オブジェクトを再利用／変更したいが情報が失われやすい |
| デバッグへの影響 | 原因箇所が見える | どこで再スローされたかにしか見えない |
実際の適用例：ログとエラー応答との兼ね合い
Web APIや業務アプリケーションでは、例外発生時にログを出して呼び出し元へ適切な応答を返すことが求められます。その際、catchでログを出したあとに throw を使うことで、例外をハンドリング層まで伝え、最終的なレスポンスやユーザーへの通知で統一的な処理ができます。throw ex を用いてしまうと、スタック解析時にどの層で発生したかが不明瞭になるため、ログの信頼性が落ちます。
例外処理とパフォーマンス、安全性、リソース管理の観点
throwを使うとき、安全で効率的なコードにするためには例外処理のパフォーマンス・安全性・リソースの扱いを意識する必要があります。ここではその観点からの実践的なアドバイスをまとめます。
例外を多用しない：例外は制御フローではなく異常用途に限定する
例外処理は例外的な状況を扱うためのものであり、通常の制御フローに使うものではありません。頻繁に例外を発生させると、スタックトレース生成や例外オブジェクト生成にコストがかかり、性能低下の原因となります。nullチェックや条件分岐で事前に異常を回避できる設計が望まれます。
リソースの確実な解放：usingとfinallyの活用
例外が発生しても破棄すべきリソースが残るとメモリリークやファイルハンドルの問題が起きます。IDisposableを実装したオブジェクトは using を使うか、finally ブロックで明示的に解放すること。これにより例外発生時にも確実なクリーンアップが保証されます。
非同期処理と例外：タスクの例外を適切に扱う
async/await を使った非同期メソッドでは例外がタスクの中で発生し、呼び出し元で await をしなかったり捕捉されなかったりすると未観測例外になる可能性があります。Task の例外は await を使うか Task. ContinueWith を使って捕捉し、必要なら throw を使って呼び出し元に伝える設計が重要です。
ExceptionDispatchInfoを使って例外情報を保持する
例外を一旦捕捉した後、別スレッドで再スローしたいようなケースがあります。その際、通常の throw や throw ex ではスタック情報が失われることがあります。ここで ExceptionDispatchInfo を使って例外の状態をキャプチャし、後で Throw メソッドで再スローすると、元のスタック情報を含めた例外が得られます。これによりデバッグ時に例外の発生元を追いやすくなります。
まとめ
C#における throw は、例外処理の要となるキーワードであり、「C# throwとは 使い方」という観点で正しく理解することが、堅牢なプログラムを書く鍵です。基本的な使い方は throw new による例外発生と、catch 内での throw による再スローです。再スローの際にはスタックトレースの保持を意識して throw 単体を使い、throw ex を避けることが重要です。
また、C#7以降の仕様で導入された throw 式を使うことで、null チェックや条件式、式本体のメンバーなどで例外を簡潔に表現できます。リソース管理や非同期処理、例外の捕捉とログ記録などと組み合わせることで、安全性と可読性のバランスの取れたコードが書けます。
コメント