A routine mechanical refactoring left four identifiers undefined in the NTK CLI. This fatal ReferenceError should have crashed the app immediately on the first test run. Instead, it was swallowed by a broad try/catch block, disguised as a routine network flake, and shipped broken to production three separate times.

A try/catch block is a safety net. But if you make the net too wide, it stops catching bugs and starts hiding them.

The Camouflage

During the refactoring, a monolithic file was split into smaller modules. The file attachment logic—where the undefined variables lived—was wrapped in a wide try/catch block originally designed to handle Notion API timeouts.

When the code executed, it hit the undefined identifiers and threw the ReferenceError. The broad catch (e) intercepted it without checking the error type. Assuming it was a network issue, the CLI confidently printed: Failed to attach files.

Because the fatal bug was camouflaged as a normal network flake, the developer assumed the Notion API was just unstable again. The broken code bypassed all suspicion and went straight to the users.

Narrow the Scope

A catch block that blindly swallows everything is a massive liability.

If you are catching an error to handle a specific failure mode (like a network timeout), you must assert that the error is actually what you expect. If it’s a ReferenceError, a TypeError, or a SyntaxError, your catch block has no business handling it.

Catch the network error. Let everything else crash loudly.

---

Next in the NTK series: how trivial, “obviously correct” utility code caused the CLI to output -Infinity in The Math.max of Empty Arrays.

• #javascript
• #refactoring
• #ntk
• #engineering