A string is not an Error

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.

"Script Error"

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.

  1. Make sure that your external assets are served with the 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).
  2. Add the crossorigin attribute to your script tag.
<script src="//" crossorigin></script>

Loading assets with CORS is not supported in Internet Explorer.