onerror event before, you’ve probably come across the following:
window.onerror – getting insight into uncaught errors in your application.
The cause: cross-origin scripts
To better understand what’s going on, consider the following example HTML document, hypothetically served from http://example.com/test:
Here’s the contents of http://another-domain.com/app.js. It declares a single function,
foo , whose invocation will always throw a ReferenceError.
"Script error.", "", 0, 0, undefined
I’m not a bad person, really!
Despite browsers’ good intentions, there are some really good reasons why you want insight into errors thrown from scripts served from different origins:
- You are using libraries served from a community CDN, like cdnjs or Google’s Hosted Libraries.
The fix: CORS attributes and headers
1) Add a crossorigin=”anonymous” script attribute
This tells the browser that the the target file should be fetched “anonymously”. This means that no potentially user-identifying information like cookies or HTTP credentials will be transmitted by the browser to the server when requesting this file.
2) Add a Cross Origin HTTP header
CORS is short for “Cross Origin Resource Sharing”, and it’s a set of APIs (mostly HTTP headers) that dictate how files ought to be downloaded and served across origins.
Access-Control-Allow-Origin: *, the server is indicating to browsers that any origin can fetch this file. Alternatively, you can restrict it to only a known origin you control, e.g.
Note: most community CDNs properly set an Access-Control-Allow-Origin header.
Once both of these steps have been made, any errors triggered by this script will report to
window.onerror just like any regular same-domain script. So instead of “Script error”, the onerror example from the beginning will yield:
"ReferenceError: bar is not defined", "http://another-domain.com/app.js", 2, 1, [Object Error]
Boom! You’re done – ”Script error” will plague you and your team no more.
An alternative solution: try/catch
Sometimes, we’re not always in a position to be able to adjust the HTTP headers of scripts our web application is consuming. In those situations, there is an alternative approach: using try/catch.
Consider the original example again, this time with try/catch:
For posterity, some-domain.com/app.js once again looks like this:
Running the example HTML will output the following 2 entries to the console:
=> ReferenceError: bar is not defined at foo (http://another-domain.com/b.js:2:3) at http://example.com/test/:15:3 => "Script error.", "", 0, 0, undefined
The first console statement – from try/catch – managed to get an error object complete with type, message, and stack trace, including file names and line numbers. The second console statement from
window.onerror, once again, can only output “Script error.”
Now, does this mean you need to try/catch all of your code? Probably not – if you can easily change your HTML and specify CORS headers on your CDNs, it is preferable to do so and stick to
But, if you don’t control those resources, using try/catch to wrap 3rd-party code is a surefire (albeit tedious) way to get insight into errors thrown by cross-origin scripts.
If this blog post helped you out, and you’d like to learn more about