Does window.onerror function preferable to window.addEventListener ('error', callback)?

Question

Assigning a function to window.onerror seems like a pretty simple way to start processing errors in the code on the page. However, it is important to make sure that you are not overwriting a previously existing error handler, so it is generally recommended that you keep a reference to the previous value and call it as part of your new function. As an example:

 var old_onerror = window.onerror; window.onerror = function() { // do something if (old_onerror) { old_onerror(); } }; 

Most of the documentation / blog posts / etc that I can find on the Internet recommends doing something like this. Why do they not recommend adding an event handler for the 'error' event? This allows you to call several functions when one of these events is triggered and does not require awkward servicing of links to other error handlers.

 window.addEventListener('error', function() {/* do something */}); 

Edit: I considered the following standard recommendations on this subject , but the error event in window seems to be a rather special case (see, for example, the apparent lack of its support in JQuery (find "onerror" on this page)). I am specifically looking for an understanding of why onerror is a special case.

Answer 1

For historical reasons, these window.onerror are a special case. Most of them no longer work, I think you need to go back to IE8 to find the browser that needed them. About ten years ago, IE6 was king, and it did not have addEventListener support at addEventListener , and many events were supported only by some browsers or had different names. Web development used to be extremely controversial, and old methods such as window.onerror were often found.

Due to backward compatibility, window.onerror bit strange, as the two methods of subscribing to an event take different arguments.

Thus, the deprecated onerror includes error parameters as parameters:

 window.onerror = function(message, source, line, col, error) { ... return true; // This will prevent further event propagation }; 

It’s still the case that the old JS that already exists will not break - browser designers want ten-year-old websites to mostly work in their latest versions.

While the event listener (currently recommended) has them as properties for the event:

 window.addEventListener('error', e => { // Get the error properties from the error event object const { message, source, lineno, colno, error } = e; }); 

The latter is much better, since you do not need to get any previous listeners, and no subsequent listeners (say, from browser extensions) will accidentally interrupt yours. You can also remove your listener if you create something like SPA, where you stay on the same page with one window context.

So, to answer the question:

Most of the documentation / blog posts / etc that I can find on the Internet recommends doing something like this. Why do they not recommend adding an event handler for the error event?

Because they are out of date. Keeping the documentation up to date is difficult, and JS is moving fast. The window.onerror template that you described is still an acceptable compromise in some enterprise environments where extremely obsolete versions of IE must be supported. For the vast majority of web addEventListener method addEventListener much better.

see, for example, the apparent lack of jQuery support (find "onerror" on this page)

JQuery is old. There are some decisions that were made in 2006-2008. Or so that they are now stuck forever, and some of the assumptions that .on makes regarding events are one of those. jQuery .on was great in 2006 because we didn't have to worry about implementing events in different browsers - it could hide them all behind a common interface. Now everything uses addEventListener so you don't need it (and it is much more powerful than .on ).