Skip to content
>devspeak
← glossary
patternCommunication Patterns

Don't mask the underlying error

Tell the agent not to hide an error just to make it go away, like catching it and ignoring it, but to deal with what's actually causing it.

a bit more technical

Rule out fixes that suppress symptoms, such as empty catch blocks, silent default values, disabled checks, skipped tests, or blanket retries, without addressing the cause. Errors that must be handled should still be logged or shown with enough context to debug.

picture it

Putting tape over your car's check-engine light. The dashboard looks fine now, but the engine problem is still there and getting worse.

✗ instead of
the import keeps throwing an error, just make the error go away
✓ try
The subscriber import throws an error. Don't mask the underlying error by catching and ignoring it, or by silently skipping rows. Find why it fails and fix that. If some rows truly can't be imported, log them and report a count.
why it matters

Asked to "make the error go away," agents sometimes do exactly that: they wrap the code so failures are silently ignored. The app looks fine while data quietly goes missing.

what your agent might say
agent
I could catch this exception to stop the crash, but that would mask the underlying error. The import fails because some rows have no email. Should those be skipped with a report, or rejected?
how you might use it
you → your agent
Fix the import crash without masking the underlying error. Don't catch the error and ignore it, and don't silently skip rows. If some rows must be skipped, log each one and tell me how many.
common mistake

Thinking "no more error messages" means fixed. Sometimes it means the problem is now invisible.

builds on