Bad exception handling turns small problems into big ones
How custom code handles errors decides whether a small problem stays small. Custom business logic that swallows exceptions, or lets them crash the wrong flow, turns a minor failure into a hidden bug or a customer-facing outage.
Exception handling is easy to get wrong in ways that are invisible until they matter. Code that hides errors looks like it works, right up until the hidden failures accumulate into something serious.
This article covers the common exception-handling mistakes in custom Magento code, why they are dangerous, and how to recognize them in a review.
The swallowed exception
The most common mistake is catching an exception and doing nothing with it. The code catches the error, suppresses it, and continues as if nothing happened, which hides the failure entirely.
This is dangerous because it removes the signal. An operation that failed leaves no log, no error, and no trace, so the consequences appear far from the cause and are nearly impossible to trace back.
Catching too broadly
Another mistake is catching everything. A catch block that captures the most general exception type treats every possible failure the same way, including ones it was never meant to handle.
This hides bugs that should have surfaced. A genuine programming error gets caught alongside the expected failure, and the code carries on, masking a problem that needed attention.
Catching specifically, only the exceptions the code knows how to handle, lets the unexpected ones propagate to where they can be seen. Broad catches turn every failure into the same silent non-event.
Crashing the wrong flow
The opposite mistake is letting an exception crash a flow it should not. A non-critical failure in custom logic that propagates up and breaks checkout, or an admin save, does far more damage than the original problem.
A logging call that fails should not stop an order from being placed. When custom code lets a minor failure crash a critical flow, it has inverted the priorities, sacrificing the important operation for the unimportant one.
Good handling contains a non-critical failure so the important flow continues. The error is logged and handled, but it does not take down the operation that actually mattered.
The missing log
Even when an exception is handled correctly, failing to log it is a mistake. A handled exception that leaves no record means the problem happened and nobody knows.
Logging the exception, with enough context to understand it, preserves the signal while still handling the failure gracefully. The operation recovers, and the record exists for someone to investigate the underlying cause.
This is the balance good handling strikes: recover from the failure so the flow continues, but record it so the failure is visible. Handling without logging loses half of that.
Why it hides in custom logic
Exception-handling problems concentrate in custom business logic because that is where shortcuts are taken under deadline. Wrapping risky code in a broad try-catch that swallows everything is the fast way to make a feature stop erroring.
It stops the visible error and creates an invisible one. The feature no longer crashes, but it now fails silently, which is worse, because the failure is hidden rather than fixed.
This pattern appears most in code written quickly, in custom modules and integrations. The rushed fix for an error is often to hide it, which is exactly the mistake.
Recognizing it in a review
These patterns are findable in the code. Empty catch blocks, catches of the most general exception type, and try-catch wrapping around critical operations are all searchable and readable.
Grepping for catch blocks and reading what they do, especially looking for empty ones and overly broad ones, surfaces the problem handling. The question for each is whether it recovers appropriately, logs the failure, and protects the right flow.
The result is a map of where the custom code hides its failures. Those are the places where small problems become big ones, and they are exactly what a code-quality review looks for.
Handling in observers and plugins
Exception handling is especially consequential in observers and plugins, because of where they run. An observer that throws during a critical event, or a plugin that fails on a core method, can break the flow it is attached to.
An observer reacting to an order event should not let its own failure stop the order. Its job is a side effect, and a failed side effect must not take down the operation it was reacting to, which means containing and logging its errors carefully.
This makes exception handling part of the mechanism-choice discussion. Where custom code hooks in decides how much damage a mishandled exception can do, which is another reason those hook points deserve careful review.
Handle failures, do not hide them
Good exception handling recovers from failures, protects critical flows, and logs what happened. Bad handling swallows errors, catches too broadly, or crashes the wrong flow, turning small problems into hidden or catastrophic ones.
Knowing how your custom code handles its failures, and whether it hides them or surfaces them, is a direct predictor of the bugs you will chase and the outages you will suffer. Reviewing that handling is a core part of a code-quality and stability review.