現場で泥臭くコードを書いていると、一度は必ずぶつかる壁がある。「例外処理をガチガチに固めたいのに、`try…catch`で捕まえたアイツが一体何者なのか判別できない」という問題だ。
JavaScriptにおけるErrorオブジェクトの判定。これ、単に `typeof` を叩いて「objectだ」と喜んでいるようでは、中級エンジニアとしてはまだ甘い。今日は、ブラウザの深淵を覗きつつ、実務で絶対に事故らない「Error判定の流儀」を叩き込んでやる。
—
1. `typeof` は役立たず、という現実
まず、初心者がやりがちなミスを訂正しておこう。
`catch (e)` で捕まえた `e` に対して `typeof e` を叩いてはいけない。これは例外なく `’object’` が返ってくるからだ。`null` も `’object’` である以上、`typeof` はErrorを判定する道具としてはあまりに解像度が低い。
では、どうするか？ 我々には `instanceof` という強力な武器がある。
try {
throw new TypeError(‘型が違うぞ！’);
} catch (e) {
// instanceof でプロトタイプチェーンを辿る
if (e instanceof TypeError) {
console.log(‘これはTypeErrorだ。型を修正して再試行すべきだ。’);
} else if (e instanceof Error) {
console.log(‘一般的なErrorだ。ログを飛ばそう。’);
}
}
2. なぜ `instanceof` が「裏切り」を生むのか
ここでエンジニアとしての嗅覚を働かせてほしい。`instanceof` は万能か？ 答えは「NO」だ。
もしお前が、iframeを跨いで通信したり、異なる実行コンテキスト（Node.jsのvmモジュールなど）で生成されたErrorオブジェクトを扱う場合、`instanceof` は無残に裏切る。「異なるグローバル環境のErrorクラス」は、プロトタイプチェーンが物理的に別物だからだ。
「じゃあどうすりゃいいんだよ！」という声が聞こえてきそうだな。ここで真打ちの登場だ。
3. 現場のベストプラクティス：`name` プロパティと `constructor.name`
実務で最も堅牢なのは、`instanceof` と `name` プロパティ（あるいは `constructor.name`）のハイブリッド戦略だ。これなら実行コンテキストが異なっても、例外の名前で確実に素性を特定できる。
以下に、どんな現場でも通用する「プロ仕様のError判定ユーティリティ」を書いておいた。そのままコピーして使っていい。
/
- 堅牢にErrorの種類を判定するためのユーティリティ
/
const isErrorType = (error, typeName) => {
// 1. まずは素直にinstanceofを試す（同一コンテキストならこれで十分）
if (error instanceof Error && error.constructor.name === typeName) {
return true;
}
// 2. 異なるコンテキスト対策：nameプロパティを直接確認する
// また、念のためオブジェクトかどうか、エラーかどうかのチェックも兼ねる
return (
error != null &&
typeof error === ‘object’ &&
‘name’ in error &&
error.name === typeName
);
};
// — 使用例 —
try {
throw new ReferenceError(‘変数が未定義だ！’);
} catch (e) {
if (isErrorType(e, ‘ReferenceError’)) {
console.error(‘解決策: スコープを確認しろ。’);
}
}
4. プロの視点：なぜここまでやるのか
「たかがエラー判定に、なぜそこまで神経質になるのか？」と思うかもしれない。
理由は単純だ。フロントエンドで発生する例外は、ユーザー体験（UX）に直結するからだ。ネットワークエラーでリトライさせるべきなのか、あるいはプログラムのバグで即座にSentryへ飛ばすべきなのか。これを判定ミスすれば、ユーザーは「何も起きない画面」を見つめる羽目になる。
エンジニアの仕事は、コードを書くことじゃない。「起こりうる最悪の事態を想定し、それをいかにスマートにハンドリングするか」だ。
今日から意識してほしいポイント
- `instanceof` は基本。ただし、外部ライブラリやiframeとの境界線では信用しない。
- `error.name` は、JavaScriptの仕様上、開発者が自由に書き換えられるという脆弱性があることも忘れるな。だからこそ、多角的に検証するんだ。
- 例外処理は「異常系を正常系に引き戻すためのチケット」だ。安易に `console.error` して放置するな。
どうだ、少しは霧が晴れたか？ こういう泥臭い仕様の隙間を埋める知識こそが、お前を「ただのコーダー」から「頼れるアーキテクト」へ押し上げるんだ。また何かあったら聞きに来い。現場からは以上だ。
コメント