Day13 前半のゴール
Day13 は「エラーが起きたら終わり」から
「エラーが起きても、ちゃんと受け止めて処理を続ける」世界に進む日です。
前半のゴールはこの2つです。
Day13 前半でつかみたい感覚
try：エラーが起きそうな処理を“囲う場所”
catch：起きてしまったエラーを“受け止める場所”
「エラー＝バグ」ではなく
「エラー＝起こりうる事実、それをどう扱うかが設計」
という感覚に近づいていきます。
そもそも「例外処理」とは何か
普通のエラーと「例外」の違い
JavaScript でエラーが起きると、
何もしていなければそこで処理が止まり、
コンソールに赤いエラーが出ます。
JSON.parse("これはJSONじゃない");
// Uncaught SyntaxError: Unexpected token ...
こういう「実行中に起きるエラー」を
プログラムの世界では「例外（Exception）」と呼びます。
例外処理とは、
「そのエラーをただ放置して止めるのではなく、
ちゃんと捕まえて、どう振る舞うかを決めること」です。
try / catch の基本形
まずは形を覚える
例外処理の基本形はこうです。
try {
// エラーが起きるかもしれない処理
} catch (error) {
// エラーが起きたときに実行される処理
}
try の中でエラーが発生すると、
その瞬間に処理の流れが catch に飛びます。
逆に、try の中でエラーが起きなければ、
catch は実行されません。
具体例：JSON.parse を安全に呼ぶ
const text = "これはJSONじゃない";
try {
const data = JSON.parse(text);
console.log("パース成功:", data);
} catch (error) {
console.log("JSONのパースに失敗しました");
}
このコードでは、
JSON.parse が成功したら → try の中の console.log が動く
JSON.parse が失敗したら → catch の中の console.log が動く
という2パターンの流れを、
明示的に書いています。
try / catch がないとどうなるか
例外が「その場でプログラムを止める」
同じ処理を try / catch なしで書くとこうなります。
const text = "これはJSONじゃない";
const data = JSON.parse(text); // ここでエラー
console.log("ここには到達しない");
JSON.parse でエラーが起きた瞬間に、
その下の console.log には一切到達しません。
ブラウザならコンソールに赤いエラーが出て、
そのスクリプトの実行はそこで止まります。
try / catch があると「落ちない」
さきほどの try / catch 版では、
エラーが起きてもプログラムは「落ちません」。
const text = "これはJSONじゃない";
try {
const data = JSON.parse(text);
console.log("パース成功:", data);
} catch (error) {
console.log("JSONのパースに失敗しました");
}
console.log("ここには到達する");
エラーが起きた場合の流れはこうです。
JSON.parse でエラー発生
→ try ブロックを途中で抜けて catch にジャンプ
→ catch の中の処理を実行
→ その後の console.log(“ここには到達する”) も実行
「エラーが起きても、アプリ全体は生きている」
これが例外処理の大きな意味です。
catch の引数 error について
error には「エラーの情報」が入っている
catch のかっこの中に書いた名前（よく error と書く）は、
発生したエラーオブジェクトそのものです。
try {
JSON.parse("これはJSONじゃない");
} catch (error) {
console.log("エラーの中身:", error);
}
ブラウザのコンソールで見ると、
エラーの種類（SyntaxError）やメッセージ、
スタックトレース（どこで起きたか）などが入っています。
メッセージだけを使うこともできる
try {
JSON.parse("これはJSONじゃない");
} catch (error) {
console.log("メッセージ:", error.message);
}
ユーザーには「パースに失敗しました」とだけ見せて、
ログには error.message や error.stack を残す、
という使い分けもよく行います。
どこを try で囲むべきか
「エラーが起きるかもしれない境界」を意識する
何でもかんでも try / catch で囲めばいいわけではありません。
例えば、こういう書き方はあまりよくありません。
try {
// ここに大量の処理を書く
// どこでエラーが起きたか分かりにくい
} catch (error) {
console.log("なんかエラー");
}
これだと、
どの処理が失敗したのか
どのエラーをどう扱いたかったのか
が分かりにくくなります。
「外部要因で失敗しうるところ」を囲う
try / catch で囲むべき典型的な場所は、
JSON.parse（外部から来た文字列）
ネットワーク通信（fetch など）
ローカルストレージの読み書き
ユーザー入力のパース
など、「外部から来るものに依存していて、
こちらでは完全にコントロールできない部分」です。
前半ではまず、
「エラーが起きそうな処理をピンポイントで try に入れる」
という感覚を持っておけば十分です。
セキュリティ・安全性の視点から見る try / catch
「落ちない」ことは安全の第一歩
セキュリティというと、
攻撃・脆弱性・暗号化…を想像しがちですが、
実は「エラーで簡単に落ちない」ことも重要な要素です。
エラーで処理が途中で止まると、
中途半端な状態でデータが保存される
ログが残らず原因が追えない
ユーザーに意味不明な画面が出る
といった問題が起きます。
try / catch でエラーを受け止めておけば、
エラー内容をログに残す
ユーザーには丁寧なメッセージを出す
必要なら安全なロールバックをする
といった「ちゃんとした振る舞い」を設計できます。
ただし「握りつぶす」のは危険
一方で、こういう書き方は危険です。
try {
JSON.parse("これはJSONじゃない");
} catch (error) {
// 何もしない
}
エラーが起きても、
何もログに残さず、何も伝えない。
これは「エラーを隠している」状態で、
セキュリティ的にも保守性の面でもよくありません。
最低限、
ログに残す
ユーザーに分かりやすいメッセージを出す
安全なデフォルト値を使う
など、「どう扱うか」を決めることが大事です。
Day13 前半のサンプルコード
try / catch の基本動作を確認する小さな例
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Day13 例外処理 前半</title>
</head>
<body>
<h1>Day13: 例外処理（前半）</h1>
<script>
const text1 = '{"name":"Taro","age":20}';
const text2 = "これはJSONじゃない";
try {
const data1 = JSON.parse(text1);
console.log("1つ目のパース成功:", data1);
} catch (error) {
console.log("1つ目のパース失敗");
}
try {
const data2 = JSON.parse(text2);
console.log("2つ目のパース成功:", data2);
} catch (error) {
console.log("2つ目のパース失敗:", error.message);
}
console.log("スクリプトは最後まで実行されました");
</script>
</body>
</html>
1つ目は成功、2つ目は失敗。
それでもスクリプト全体は最後まで動きます。
Day13 前半のまとめ
try は「エラーが起きるかもしれない処理を囲う場所」。
catch は「起きたエラーを受け止めて、どう振る舞うかを書く場所」。
エラーを「ただのクラッシュ原因」として放置するのではなく、
「起こりうる事実」として設計に組み込むのが、
例外処理の本質です。
後半では、
エラー内容をログに残す
安全なデフォルト値で処理を続ける
ユーザー向けメッセージと開発者向けログを分ける
といった、より実務寄りの例外処理のパターンに踏み込んでいきます。