Error Handling Done Right

Error handling is how your application responds when something goes wrong. It is the difference between your app crashing with an ugly stack trace and your app showing a friendly message that says "Something went wrong, here is what you can do."

Good error handling has multiple layers. At the lowest level, individual functions need to catch and handle errors from operations that can fail (API calls, database queries, file operations). At the component level in React, error boundaries catch rendering errors and display fallback UI instead of breaking the entire page. At the route level, error pages catch anything that slips through and give users a way to navigate back to working parts of the app.

AI-generated code tends to be optimistic — it assumes everything works. You will find lots of async/await without try/catch, API calls without error handling, and components that break spectacularly when they receive unexpected data. This is because the AI was focused on the happy path: the scenario where everything goes right.

Error messages also need to be accessible. WCAG Success Criterion 4.1.3 requires that status messages be programmatically determinable without receiving focus. That means using aria-live regions for non-critical updates, role="alert" for critical errors, aria-invalid="true" on form fields with problems, and aria-describedby linking errors to inputs. The error container must be in the DOM on page load — dynamically injected live regions may not be announced by screen readers.

The CrowdStrike outage is the most expensive error handling failure in history — $5.4 billion in Fortune 500 losses from one unhandled exception. Only 10-20% was insured. Delta Air Lines filed a $500 million lawsuit. CrowdStrike's own terms of service limit liability to "fees paid."

But you do not need a global outage to see the cost. One hour of system downtime costs enterprises $300,000 on average. The MOVEit vulnerability that exposed 93.3 million records and cost $9.93 billion was fundamentally an input validation failure — a SQL injection, which is what happens when your code does not handle unexpected input.

The Therac-25 radiation therapy machine killed or severely injured at least six patients because the software contained no self-checks, no error-detection features, and no error-handling code. A race condition delivered lethal radiation doses — something simple assertion checks or watchdog timers would have caught. Hardware safety interlocks were removed because developers trusted the software.

Users judge your app by how it handles failure, not just success. Consider two scenarios: a user fills out a long form, hits submit, and the API fails. In scenario one, the page goes white. Data gone. User gone. In scenario two, the form shows a message, preserves their data, and lets them retry. Both had the same error. The second one kept its user.