onerror
/ˈɒnˌɛrər/
noun … “an event handler for error conditions.”
onerror is an event handler used in web and programming environments to detect and respond to errors at runtime. It acts as a kind of early-warning system … when something fails, breaks, or refuses to load, onerror is where control flows next.
In the browser world, onerror most commonly appears in two related contexts: global JavaScript error handling and resource-loading errors. Both serve the same philosophical role … catching failures before they disappear into silence.
At the global level, onerror can be attached to the window object. When an uncaught JavaScript exception occurs … a syntax error, a reference to an undefined variable, or a runtime crash … the handler is triggered. This allows developers to log diagnostic data, display fallback UI, or report failures to monitoring systems rather than letting the application fail invisibly.
Resource handling is the second major domain. HTML elements such as images, scripts, audio, and video can define an onerror handler that fires when loading fails. A missing image file, a blocked script, or a network interruption all surface through this mechanism. Instead of showing a broken icon or silently failing, the application can react intelligently … load a fallback asset, retry, or notify the user.
Conceptually, onerror is part of the event-driven programming model. Rather than checking for failure after every operation, the system emits an error event when something goes wrong. The handler listens for that event and responds asynchronously. This fits naturally with non-blocking systems and complements constructs like async, await, and promises.
One important subtlety is scope. A global onerror handler catches only errors that escape local control. Errors that are already handled inside a try/catch block never reach it. This makes onerror a safety net, not a replacement for proper error handling logic.
Security and privacy also shape how onerror behaves. Browsers intentionally limit the information exposed for certain cross-origin errors. Instead of detailed stack traces, the handler may receive only a generic message. This prevents sensitive internal details from leaking across trust boundaries, even though it can make debugging more challenging.
Outside the browser, similar ideas exist in other runtimes. Server-side JavaScript environments expose comparable hooks for uncaught exceptions and fatal errors, though the exact APIs differ. The shared principle remains the same … centralized observation of failure.
Philosophically, onerror acknowledges an uncomfortable truth of computing: things will fail. Networks drop packets. Files go missing. Assumptions collapse. Rather than pretending perfection is possible, onerror provides a structured place to respond when reality intrudes.
Used thoughtfully, onerror turns crashes into data and confusion into recovery paths. Used carelessly, it can mask serious bugs by swallowing failures without fixing root causes. Like most powerful tools, its value lies not in its existence, but in how deliberately it is applied.