Diagnosing CoffeeScript TypeErrors: When the Existential Operator Is Missing

The condition you are seeing

Your compiled CoffeeScript runs fine in development, then production data arrives with a missing field and the browser or Node console reports TypeError: Cannot read property 'name' of undefined (or of null). The stack trace points into generated JavaScript, not your .coffee source, which makes the bug feel harder to find than it is. The usual root cause: a chain of property accesses assumed every intermediate value existed, and CoffeeScript's existential operator (?.) was never applied.

The takeaway: ?. compiles to a null/undefined guard, so user?.address?.city evaluates to undefined instead of throwing when user or address is missing. The sections below walk through confirming that diagnosis and fixing it without masking real bugs.

Cause and diagnostic table

Ordered checks

1. Map the stack trace back to source. If you compile with source maps (coffee -c -m file.coffee), the browser debugger will show the original CoffeeScript line. Otherwise, match the generated property name to your source.
2. Identify which value can be absent. Add a temporary log or breakpoint: console.log user, user?.address just before the failing access. Note whether it is null, undefined, or an unexpected type.
3. Check each link in the chain. In a.b.c.d, any of a, b, or c can be the null one. The operator must guard every uncertain link: a?.b?.c?.d.
4. Inspect the compiled output. Run coffee -c file.coffee (run in your project directory; requires the coffeescript package installed globally or via npx coffee). Open the generated .js and confirm the access is wrapped in a guard such as if (user != null) or a ternary. If you see a bare user.address.city, the operator never made it in.
5. Confirm the compiler version. The existential operator requires CoffeeScript 1.7 or later. On older releases the safest path is an explicit guard (if user? then user.address) or an upgrade.

Fixes tied to findings

Missing operator on a nullable chain

Replace raw access with the existential operator at every link that can be absent:

# Before: throws when order or customer is missing
total = order.customer.address.city

# After: evaluates to undefined instead
city = order?.customer?.address?.city

Compiled, the second form becomes nested != null checks. You can then supply a default with the existential value operator: city = order?.customer?.address?.city ? "unknown". Note the distinction: ?. guards property access; ? between expressions means "use the right side if the left is null or undefined." Both compile in CoffeeScript 1.7+ and current CoffeeScript 2.x.

Null is not actually acceptable

If a missing value indicates bad data rather than an optional field, do not silence it. Fail loudly at the boundary instead:

throw new Error("order.customer is required") unless order?.customer?

This keeps the crash but moves it next to the cause, with a message a human can act on.

Function calls on possibly missing objects

The operator also guards calls: callback?() invokes the function only if it exists, and obj.method?(args) calls the method only when present. Use this for optional hooks instead of wrapping every call in if.

Verifying the fix

1. Recompile and re-read the generated JavaScript; confirm the guard exists where the bare access used to be.
2. Exercise the failing path deliberately: call the function with null, undefined, and a complete object. Expected results are undefined (or your default), undefined, and the real value — no exception.
3. Run your existing test suite to catch regressions where code depended on the throw.

Limitations and when to escalate

?. only guards against null and undefined; it does nothing for wrong types (a string where an object was expected will still throw on the next access). Overusing it can also hide genuine logic errors — if every field is guarded, a completely malformed payload sails through silently and corrupts state downstream. Guard the links that are legitimately optional; validate the rest.

Escalate beyond this fix when: TypeErrors persist after guards are in place (suggests a type mismatch, not nullability); the codebase has many similar sites (add unit tests that pass null fixtures through public functions, using your existing runner such as Mocha); or null-safety bugs recur across releases, at which point CoffeeScript 2's cleaner output plus a gradual TypeScript migration gives you static null checking that runtime guards cannot.