JavaScript exception handling detailed explanation_javascript skills

Front-end engineers all know that JavaScript has basic exception handling capabilities. We can throw new Error(), and the browser will also throw an exception when we make an error when calling the API. But it is estimated that most front-end engineers have never considered collecting this abnormal information

Anyway, as long as the JavaScript error does not reappear after refreshing, the user can solve the problem by refreshing, and the browser will not crash. Just pretend that it did not happen. This assumption held true before Single Page Apps became popular. The status of the current Single Page App becomes extremely complicated after running for a period of time. The user may have performed several input operations before arriving here. Should it be refreshed when it is said to be refreshed? Shouldn’t the previous operation be completely redone? So we still need to capture and analyze these exception information, and then we can modify the code to avoid affecting the user experience.

How to catch exceptions

We wrote our own throw new Error(). Of course we can catch it if we want to, because we know exactly where throw is written. However, exceptions that occur when calling browser APIs are not necessarily easy to catch. Some APIs are written in the standards to throw exceptions, and some APIs are only thrown by individual browsers due to implementation differences or defects. For the former, we can also catch it through try-catch. For the latter, we must listen to the global exception and then catch it.

try-catch

If some browser APIs are known to throw exceptions, then we need to put the call in try-catch to prevent the entire program from entering an illegal state due to errors. For example, window.localStorage is such an API. It will throw an exception after writing data exceeds the capacity limit. This will also be the case in Safari's private browsing mode.

Copy code The code is as follows:

try {
localStorage.setItem('date', Date.now());
} catch (error) {
reportError(error);
}

Another common use case for try-catch is callbacks. Because the code of the callback function is beyond our control, we have no idea about the quality of the code or whether other APIs that will throw exceptions will be called. In order to prevent other code after calling the callback from being unable to execute due to callback errors, it is necessary to put the call back into try-catch.

Copy code The code is as follows:

listeners.forEach(function(listener) {
try {
listener();
} catch (error) {
reportError(error);
}
});

window.onerror

For areas that are not covered by try-catch, if an exception occurs, it can only be caught through window.onerror.

Copy code The code is as follows:

window.onerror =
function(errorMessage, scriptURI, lineNumber) {
reportError({
message: errorMessage,
script: scriptURI,
line: lineNumber
});
}

Be careful not to be clever and use window.addEventListener or window.attachEvent to listen for window.onerror. Many browsers only implement window.onerror, or only the implementation of window.onerror is standard. Considering that the draft standard also defines window.onerror, we can just use window.onerror.

Attributes lost

Suppose we have a reportError function that collects captured exceptions and then sends them to server-side storage in batches for query and analysis. What information do we want to collect? The more useful information includes: error type (name), error message (message), script file address (script), line number (line), column number (column), and stack trace (stack). If an exception is caught through try-catch, this information is on the Error object (supported by mainstream browsers), so reportError can also collect this information. But if it is captured through window.onerror, we all know that this event function only has 3 parameters, so the unexpected information of these 3 parameters is lost.

Serialized message

If the Error object is created by ourselves, then error.message is controlled by us. Basically, whatever we put into error.message, the first parameter (message) of window.onerror will be. (The browser will actually make slight modifications, such as adding the 'Uncaught Error: ' prefix.) Therefore, we can serialize the properties we care about (such as JSON.Stringify) and store them in error.message, and then read them in window.onerror Just take it out and deserialize it. Of course, this is limited to Error objects we create ourselves.

The fifth parameter

Browser manufacturers also know the limitations that people face when using window.onerror, so they began to add new parameters to window.onerror. Considering that only the row number but no column number seems not very symmetrical, IE first adds the column number and puts it in the fourth parameter. However, everyone is more concerned about whether they can get the complete stack, so Firefox said it would be better to put the stack in the fifth parameter. But Chrome said that it is better to put the entire Error object in the fifth parameter. You can read any properties you want, including custom properties. As a result, Chrome moved faster and implemented a new window.onerror signature in Chrome 30, which led to the standard draft being written accordingly.

Copy code The code is as follows:

window.onerror = function(
errorMessage,
scriptURI,
lineNumber,
columnNumber,
error
) {
if (error) {
reportError(error);
} else {
reportError({
message: errorMessage,
script: scriptURI,
line: lineNumber，
column: columnNumber
});
}
}

Attribute regularization

The names of the Error object attributes we discussed before are based on Chrome’s naming method. However, different browsers name the Error object attributes differently. For example, the script file address is called script in Chrome but is called filename in Firefox. . Therefore, we also need a special function to normalize the Error object, that is, to map different attribute names to unified attribute names. For specific methods, please refer to this article. Although browser implementations will be updated, maintaining such a mapping table manually is not too difficult.

Similar to the stack trace format. This attribute saves a stack of exception information in the form of plain text. Since the text format used by each browser is different, it is also necessary to maintain a regular expression manually to extract the function of each frame from the plain text. Name (identifier), file (script), line number (line) and column number (column).

Security restrictions

If you have also encountered an error with the message 'Script error.', you will understand what I am talking about. This is actually a browser limitation for script files from different origins. The reason for this security restriction is this: assuming that the HTML returned by an online bank after a user logs in is different from the HTML seen by anonymous users, a third-party website can put the URI of the online bank into the script.src attribute. Of course, HTML cannot be parsed as JS, so the browser will throw an exception, and the third-party website can determine whether the user is logged in by parsing the location of the exception. For this reason, the browser filters all exceptions thrown by script files from different sources until only a single unchanged message like 'Script error.' is left, and all other attributes disappear.

For websites of a certain scale, it is normal for script files to be placed on a CDN with different sources. Now even if you build your own small website, common frameworks such as jQuery and Backbone can directly reference the versions on public CDNs to speed up user downloads. So this security restriction does cause some trouble, causing the exception information we collect from Chrome and Firefox to be useless 'Script error.'

CORS

To bypass this restriction, just ensure that the script file and the page itself have the same origin. But putting the script file on a server that is not accelerated by CDN will not slow down the user's download speed? One solution is to continue placing the script file on the CDN, use XMLHttpRequest to download the content back through CORS, and then create a <script> tag to inject it into the page. The code embedded in the page is of course from the same source. </script>

This sounds simple, but there are many details to implement. To use a simple example:

Copy code The code is as follows:

">http://cdn.com/step1.js">>
<script><br /> (function step2() {})();<br /> </script>
">http://cdn.com/step3.js">>

We all know that if there are dependencies between step1, step2, and step3, they must be executed strictly in this order, otherwise an error may occur. The browser can request the files of step1 and step3 in parallel, but the order is guaranteed during execution. If we obtain the file contents of step1 and step3 ourselves through XMLHttpRequest, we need to ensure the correctness of their order. In addition, don't forget step2. Step2 can be executed when step1 is downloaded in a non-blocking manner, so we must also manually intervene in step2 to let it wait for step1 to complete before executing it.

If we already have a set of tools to generate <script> tags for different pages on the website, we need to adjust this set of tools to make changes to the <script> tags: </script>

Copy code The code is as follows:

<script><br /> scheduleRemoteScript('http://cdn.com/step1.js');<br /> </script>
<script><br /> scheduleInlineScript(function code() {<br /> (function step2() {})();<br /> });<br /> </script>
<script><br /> scheduleRemoteScript('http://cdn.com/step3.js');<br /> </script>

We need to implement the two functions scheduleRemoteScript and scheduleInlineScript, and ensure that they are defined before the first <script> tag that references an external script file, and then the remaining <script> tags will be rewritten into the above form. . Note that the step2 function that was originally executed immediately has been placed in a larger code function. The code function will not be executed, it is just a container, so that the original code of step 2 can be retained without escaping, but will not be executed immediately. <p>Next we need to implement a complete mechanism to ensure that the file content downloaded by scheduleRemoteScript based on the address and the code directly obtained by scheduleInlineScript can be executed one after another in the correct order. I won’t give the detailed code here. If you are interested, you can implement it yourself. <p><strong>Reverse line number check <p>Getting content through CORS and then injecting code into the page can break through security restrictions, but it will introduce a new problem, which is line number conflict. Originally, error.script could be used to locate the unique script file, and error.line could be used to locate the unique line number. Now, since they are all codes embedded in the page, multiple <script> tags cannot be distinguished by error.script. However, the line number inside each <script> tag starts from 1. As a result, we Exception information cannot be used to locate the source code location where the error is located. <p>In order to avoid line number conflicts, we can waste some line numbers so that the line number ranges used by the actual code in each <script> tag do not overlap with each other. For example, assuming that the actual code in each <script> tag is no more than 1000 lines, then I can let the code in the first <script> tag occupy lines 1–1000, and let the second The code in the <script> tag occupies lines 1001–2000 (insert 1000 blank lines before it), and the code in the third <script> tag occupies lines 2001–3000 (insert 2000 blank lines before it). And so on. Then we use the data-* attributes to record this information for easy retrieval. <p><div class="codetitle"><span><a style="CURSOR: pointer" data="94831" class="copybut" id="copybut94831" onclick="doCopy('code94831')"><U>Copy code The code is as follows:<div class="codebody" id="code94831"><br /> <script<br /> data-src="<a href="http://cdn.com/step1.js">http://cdn.com/step1.js"<br /> data-line-start="1"<br /> ><br /> // code for step 1<br /> </script>

<script></script> data-src="http://cdn.com/step3.js"
data-line-start="2001"
>
// 'n' * 2000
// code for step 3



After this processing, if the error.line of an error is 3005, it means that the actual error.script should be 'http://cdn.com/step3.js', and the actual error.line should be 5 . We can complete this line number reverse check in the reportError function mentioned earlier.

Of course, since we cannot guarantee that each script file has only 1000 lines, and some script files may be significantly less than 1000 lines, there is no need to allocate a fixed range of 1000 lines to each <script> tag. We can allocate intervals based on the actual number of script lines, as long as the intervals used by each <script> tag do not overlap. </script>

crossorigin attribute

The security restrictions imposed by browsers on content from different sources are of course not limited to the <script> tag. Since XMLHttpRequest can break through this limitation through CORS, why can't resources referenced directly through tags? Of course this is possible. </script>

The restrictions on the <script> tag referencing script files from different sources also apply to the <img alt="JavaScript exception handling detailed explanation_javascript skills" > tag referencing image files from different sources. If an <img alt="JavaScript exception handling detailed explanation_javascript skills" > tag is from a different source, once it is used in <canvas> drawing, the <canvas> will become write-only, ensuring that websites cannot steal unauthorized image data from different sources through JavaScript. Later the <img alt="JavaScript exception handling detailed explanation_javascript skills" > tag solved this problem by introducing the crossorigin attribute. If you use crossorigin="anonymous", it is equivalent to anonymous CORS; if you use `crossorigin="use-credentials", it is equivalent to CORS with authentication. </script>

If the tag can do this, why can’t the <script> tag do the same? So browser manufacturers added the same crossorigin attribute to the <script> tag to solve the above security restrictions. Chrome and Firefox currently support this attribute without any problems. Safari will treat crossorigin="anonymous" as crossorigin="use-credentials". As a result, if the server only supports anonymous CORS, Safari will treat the authentication as failed. Since the CDN server is designed to only return static content for performance reasons, it is impossible to dynamically return the HTTP Header required for CORS authentication based on the request. Safari cannot use this feature to solve the above problems. </script>

Summary

JavaScript exception handling seems very simple, no different from other languages, but it is actually not that easy to catch all the exceptions and then analyze the attributes. Although there are some third-party services that provide Google Analytics-like services that capture JavaScript exceptions, if you want to understand the details and principles, you still have to do it yourself.