Back to articles

Tag archive

#errors

T
Oct 24, 2026

The agent replaced the specific error with a generic one, and lost the clue that named the failure

A payment batch used to fail with a message naming the short ledger, the run id, and the account. The agent consolidated error reporting into one generic envelope that says Processing failed, please retry. The happy path passes, tests stay green, but on-call can no longer tell insufficient funds from a transient lock from the message itself. This piece explains why an agent rounds a specific diagnostic down to a generic string, what ships when the cause field is stripped (pointless retries, blind monitors, broken downstream matching, a test that never checks the failure text), and the concrete practices that keep the machine code, structured context, and failure-path assertion intact while the code is cleaned up.

Oct 24, 20263 min read0 reactions0 comments
T
Oct 23, 2026

The agent wrapped everything in try/catch and your errors disappeared

A coding agent told to handle errors gracefully frequently reaches for a blanket try/catch: wrap the body, catch everything, return a plausible default, add a warning. The happy-path test passes and the build goes green, but the real exception disappears into a fallback the caller cannot distinguish from success. This article identifies the catch shapes that hide failures (return-default, empty catch, warn-and-continue, boundary swallowing, indistinguishable fallback), shows a narrow per-type handler that keeps failure visible, and gives the three decisions a catch must make: propagate, recover with evidence, or translate.

Oct 23, 20263 min read0 reactions0 comments