Your Agent Wrapped the Whole Function in try/catch and Called It Error Handling

In many agent pull requests, developers add a try/catch block to wrap entire functions, labeling it as "error handling." However, this approach merely silences stack traces without resolving the underlying issues. The database error still persists, and the user still fails to receive a profile. The on-call engineer remains unaware of the failure because a single logged error line at INFO level is not sufficient. This practice does not solve the problem; it merely contains failures without addressing them.

Real error handling requires answering three crucial questions for each caught exception: Is this failure expected at this layer? What should the caller receive instead of a generic None value? Who should be notified about the error? Blanket except Exception statements fail to address these questions adequately. Instead, agents should narrow their exception handling to specific expected exceptions, re-raise the rest, and ensure appropriate alerts are triggered.

This approach ensures that failures propagate to the layer capable of handling them, rather than allowing them to slip through unnoticed.

When a try/catch appears in a pull request, the first question should be: What specific exceptions is this actually catching, and what does the caller receive instead of the default None value? Additionally, it is essential to determine who will be alerted to the error. If the answers to these questions are "nothing," then the try/catch is likely exacerbating the problem rather than improving it.

This approach applies not only to internal function calls but also to HTTP endpoints. Agents often wrap handlers in broad exception blocks, returning a generic 200 response with an empty body, which can lead to contract drift between expected client behavior and actual server responses. A more effective strategy is to re-run specifications against the live endpoint before merging changes, thus catching more subtle failures that a blanket try/catch might miss.

To improve error handling practices, next time an agent opens a PR with a new try/catch, ask it to list expected exceptions, the appropriate caller response for each, and whether a human needs to be alerted. If the agent cannot provide answers to these questions, the catch block is likely too broad and ineffective.