落ちた場所と、壊れた場所は違う

小さな3段を作りました。API 応答をアプリの形に写し、キャッシュに入れ、後で表示します。

// load.mjs(全文)
// API の応答をアプリの形に写す
export function toUser(json) {
  return {
    name: json.name,
    address: json.adress,        // 綴り違い。ここで undefined が入る(例外は出ない)
  };
}

// view.mjs
export function label(user) {
  return `${user.name}(${user.address.city})`;   // ここで初めて落ちる
}

// main.mjs(抜粋)
put(1, toUser(response));          // 値が入るのはここ
setTimeout(() => {
  console.log(label(get(1)));      // 落ちるのはここ
}, 10);

$ node main.mjs
file:///…/l6/view.mjs:2
return `${user.name}(${user.address.city})`;   // ここで初めて落ちる
                                    ^
 
TypeError: Cannot read properties of undefined (reading 'city')
  at label (file:///…/l6/view.mjs:2:39)
  at Timeout._onTimeout (file:///…/l6/main.mjs:10:15)
  at listOnTimeout (node:internal/timers:685:17)
  at process.processTimers (node:internal/timers:618:7)
 
Node.js v24.21.0

自分のファイルは view.mjs:2:39(読んだ行)と main.mjs:10:15(呼んだ行)だけです。綴りを間違えた load.mjs:5 も、キャッシュに入れた main.mjs:6 も、一度も出ません。

スタックトレースが持つのは、落ちた瞬間に続いていた呼び出しの連なりです。load.mjs:5 が出ないのは、toUser が undefined を入れてすでに正常に戻っているからです。さらに setTimeout を挟んだので、main.mjs:6 を含むモジュール最上位の呼び出しも残りません。確かめた版では最上位の main-checked.mjs:6:8 が出ます(確認したのは setTimeout のコールバックの場合だけで、await の場合は確かめていません)。

Angular コースの「エラーメッセージの解剖 — NGコードとスタックトレース」は、自分のファイル名が出ている行から調査を始めると書いています。その通りです。この回が足すのは、始めた場所から逆向きに進むことです。

第7期『JSONとAPI — ブラウザ以外の相手に返す』では、Node が JSON の 9007199254740993 を 9007199254740992 として読みました。例外は出ません。

あの回は「どちらも壊れていません」と書いています。RFC 8259 は数値の精度を規定しておらず、Node も Python も準拠しています。

それでも食い違いは起きます。値が変わるのは受け取る側の数値型に写した瞬間で、それが問題として見えるのは、後でその id を比べたり表示したりするときです。落ちた場所から逆向きにたどると、パースの行に行き着きます。しかしその行は仕様どおりに動いています。

ここでは、比べる基準の側が誤っていました。「JSON で送れば同じ値が届く」という前提が、範囲の外では成り立たないのです。壊れた場所が、コードの行ではなく前提であることがあります。 逆向きにたどるときの比較の基準は、自分で書いた期待であり、その期待自体を疑う必要があります。