導入
文法は正しくても、実行してみて初めて起きるエラーがあります。これが**実行時エラー(例外)**です。どの例外が・どこで起きたかを示す情報を読み解けるようになりましょう。
図解
flowchart TB
RUN["実行中"] --> E["例外発生"]
E --> INFO["例外の情報"]
INFO --> T["例外の型<br/>例: FormatException"]
INFO --> M["メッセージ<br/>何が起きたか"]
INFO --> ST["スタックトレース<br/>どこで起きたか(呼び出しの経路)"]
サンプル
// 文法は正しいが、実行すると例外が起きるコード
string input = "12x";
int number = int.Parse(input); // "12x" は数値にできない → 実行時エラー
Console.WriteLine(number);
これを実行すると、次のような例外が出ます。
System.FormatException: 入力文字列が正しい形式ではありませんでした。
System.FormatException— 例外の型。「形式(フォーマット)の問題」だと分かる- メッセージ — 「入力文字列が正しい形式ではない」=変換できない文字が混じっている
- 対処: そもそも変換前に
int.TryParseを使えば、例外を出さずに失敗を検知できる(例外処理の章で学んだ通り)
例外の型名は、そのまま検索するとほぼ必ず解決策が見つかります。型名を読むのが第一歩です。
演習
string value = "abc";
// TODO: int.TryParse を使い、変換できないこの値に対して "数値ではありません" と出力してください
// (例外を出さずに失敗を検知する)
___
- 期待される出力:
数値ではありません
ヒント1を見る
if (int.TryParse(value, out int n)) ... else ...
ヒント2を見る
if (!int.TryParse(value, out int n)) Console.WriteLine("数値ではありません");
まとめ
- 実行時エラー(例外)は実行してみて初めて起きる
- 「例外の型・メッセージ・スタックトレース」で原因と場所を掴む
- 型名を検索し、可能なら
TryParse等で例外自体を避ける
次回: バグの居場所を突き止める「デバッグの考え方」です。