In JavaScript you can throw any type of data that you'd like:
throw "hello";
throw { name: "Nicholas" };
throw true;
throw 12345;
throw new Date();
Doing so will cause an error to be thrown, but from a debugging point of view this is not optimal because those primitives do not carry enough meaningful information as Error
objects.
Besides holding the message passed to the constructor, Error
objects keep track of where they were built and originated using the stack
property. This property is specific to each JavaScript engine and/or browser that implements it.
For this reason the handler is only able to report primitive errors as error messages, without full stack trace.
When an error occurs in a script, loaded from a different origin, the details of the error are not reported (to the window.onerror
callback) to prevent leaking information. Instead the error reported is simply "Script error", without details about what the error is, nor from which code it’s originating.
"Script error.", "", 0, 0, undefined
This isn't a JavaScript bug because browsers intentionally hide errors originating from script files from different origins for security reasons. For this reason, browsers only give window.onerror
insight into errors originating from the same domain.
This behavior can be overriden in some browsers using the crossorigin
attribute on <script>
and having the server send the appropriate CORS HTTP response headers.
Access-Control-Allow-Origin: *
CORS header. Most CDNs are already configured appropriately, but you should apply this change to your hosted assets (for example, if they are provided from a different cookieless domain).<script src="//cdn.example.com/site.js" crossorigin></script>
Loading assets with CORS is not supported in Internet Explorer.