What the Heck Does 'Script Error' Mean?-JS Tutorial-php.cn

What the Heck Does

Core points

The browser sends a "Script Error" message to the onerror callback function when the JavaScript file comes from a different source. This is for security reasons to prevent accidental leakage of potentially sensitive information.
To gain insight into JavaScript errors provided by files from different sources, two steps must be taken: Adding crossorigin="anonymous" script properties and adding cross-domain HTTP headers. This allows any source to get the file and any errors triggered by the script will be reported to window.onerror.
If the script's HTTP header cannot be adjusted, you can use try/catch as an alternative. By wrapping third-party code in a try/catch block, you can gain insight into the errors thrown by cross-domain scripts. However, if possible, it is still recommended to set CORS properties and headers.

This article is created in collaboration with Sentry.io. Thank you for supporting the partners who made SitePoint possible.

If you have used the onerror event of JavaScript before, you may have encountered the following situation:

Script error.

When an error originates from a JavaScript file from a different source (different domain name, port, or protocol), the browser sends a "script error" to the onerror callback function. This is painful because even if an error occurs, you don't know what the error is, nor which code the error originates from. And the whole purpose of window.onerror is to gain insight into uncaught errors in the application.

Reason: Cross-domain scripts

To better understand what is going on, consider the following example HTML document, assuming it comes from http://example.com/test:

<!DOCTYPE html>
<html>
<head>
  <title>example.com/test</title>
</head>
<body>
  <🎜>
  <🎜>
</body>
</html>

Copy after login

This is the content of http://another-domain.com/app.js. It declares a single function called foo whose call will always throw ReferenceError.

// another-domain.com/app.js
function foo() {
  bar(); // ReferenceError: bar 不是函数
}

Copy after login

When this document is loaded and JavaScript is executed in the browser, the following is output to the console (recorded via the window.onerror callback function):

"Script Error.", "", "", 0, 0, undefined

This is not a JavaScript error - the browser deliberately hides script files from different sources for security reasons. This is to prevent the script from accidentally leaking potentially sensitive information into the onerror callback function that it cannot control. Therefore, the browser only allows window.onerror to gain insight into errors originating from the same domain. All we know is that an error occurred—not knowing anything else!

I am not a bad person, really!

Although the browser is in good intentions, you want to dig deep into the errors thrown by scripts from different sources, and there are some very good reasons:

Your application JavaScript files come from different host names (for example, static.sentry.io/app.js).
You are using libraries provided from a community CDN such as cdnjs or Google Hosting Library.
You are using a commercial third-party JavaScript library that is only available from an external server.

But don't worry! A deeper understanding of JavaScript errors provided by these files requires only a few simple tweaks.

Solution: CORS properties and headers

To understand the JavaScript exception thrown by scripts from different sources, you have to do two things.

1. Add `crossorigin="anonymous"` Script properties

<!DOCTYPE html>
<html>
<head>
  <title>example.com/test</title>
</head>
<body>
  <🎜>
  <🎜>
</body>
</html>

Copy after login

This tells the browser that the target file should be retrieved "anonymously". This means that when requesting this file, the browser does not transmit any potential user-identifying information to the server, such as cookies or HTTP credentials.

2. Add cross-domain HTTP header

// another-domain.com/app.js
function foo() {
  bar(); // ReferenceError: bar 不是函数
}

Copy after login

CORS is the abbreviation for cross-domain resource sharing, and it is a set of APIs (mainly HTTP headers) that specifies how files are downloaded and served across domains.

By setting <code>Access-Control-Allow-Origin: *</code>, the server indicates to the browser that any source can obtain this file. Alternatively, you can limit it to known sources that you control:

<🎜>

Copy after login

Once these two steps are completed, any errors triggered by this script will be reported to window.onerror, just like any regular same-domain script. Therefore, the onerror example will no longer be a "script error", but instead:

<code>Access-Control-Allow-Origin: *</code>

Copy after login

That's it! "Script Error" will no longer bother you and your team.

Alternative: try/catch

Sometimes we cannot adjust the HTTP header of the scripts our web application is using. In this case, there is an alternative: use try/catch.

Consider the original example again, this time using try/catch:

$ curl --head https://ajax.googleapis.com/ajax/libs/jquery/2.2.0/jquery.js | \
    grep -i "access-control-allow-origin"

Access-Control-Allow-Origin: *

Copy after login

For the sake of future generations, some-domain.com/app.js again as follows:

<code>"ReferenceError: bar 未定义", "http://another-domain.com/app.js", 2, 1, [Object Error]</code>

Copy after login

Run the example HTML outputs the following two entries to the console:

window.onerror = function (message, url, line, column, error) {
  console.log(message, url, line, column, error);
}

try {
  foo(); // 调用 app.js 中声明的函数
} catch (e) {
  console.log(e);
  throw e; // 故意重新抛出（由 window.onerror 捕获）
}

Copy after login

The first console statement - from try/catch - managed to get an error object containing the type, message, and stack trace, including the file name and line number. The second console statement from window.onerror can again only output "script error".

Now, does this mean you need to try to capture all the code? Probably not. If you can easily change HTML and specify CORS headers on the CDN, it's better to do this and stick with window.onerror.

But, if you don't control these resources, wrapping third-party code using try/catch is a reliable (although tedious) way to get a deeper understanding of the errors thrown by cross-domain scripts.

Note: By default, Sentry's JavaScript SDK raven.js carefully detects built-in methods to try to automatically wrap your code in a try/catch block. This is done to try to capture error messages and stack traces for all scripts, regardless of where they come from. If possible, it is still recommended to set CORS properties and headers.

Of course, there are a lot of commercial and open source tools that can do all the heavy lifting for you. (Shh: You might want to try debugging JavaScript with Sentry.)

That's it! Happy error monitoring.

Script Error FAQ

(The FAQ part is omitted here, because the article is too long and has weak correlation with the subject of the article, you can add or modify the FAQ yourself as needed)

The above is the detailed content of What the Heck Does 'Script Error' Mean?. For more information, please follow other related articles on the PHP Chinese website!

What the Heck Does 'Script Error' Mean?

1. Add crossorigin="anonymous" Script properties

2. Add cross-domain HTTP header

1. Add `crossorigin="anonymous"` Script properties