An idea for JS exception handling (sofish)_javascript skills

Perhaps due to network, browser problems, cache, etc., the online execution of js may be different from the development environment, and an exception may be thrown. js exceptions are basically a daily routine for front-end development engineers. How to record and use it, but few people pay attention to it. I've been thinking about an idea recently, which basically involves two steps: collection and use.

1. Collection
For error collection, it is quite convenient, because there is an interface in each browser: window.onerror, the code is as follows:

Copy code The code is as follows:

window.onerror = function(errorMessage, scriptURL, lineNumber) {
alert(errorMessage, scriptURL, lineNumber)
}

Even provides Stack Trace, such as e.stack in try/catch (each browser is different, you can use eriwen /javascript-stacktrace compatibility library), try the following code:

Copy the code The code is as follows:

try {
fn()
} catch(e) {
alert(e.stack)
}

So it is more convenient to collect these errors Yes, something to note here is that the first parameter of callback when using window.addEventListener('error', callback, isBubble) is not an event, but an Error object. In this case, for convenience, using window.onerror is a good choice, but the events monitored through the dot operator can be overloaded, and this listening script is theoretically placed at the front of all js, so it needs to be considered risk.

2. Use
When using Alipay before, the online js error report would be turned into an email and sent to the front-end development team, and everyone would claim and solve it themselves. In fact, this is a good choice, and it also solves the most basic problem: respond immediately and repair it. But there is also a problem, how to avoid the same mistake? My initial idea is as follows: Use URL as a unit to record errors on the same page: to facilitate unified resolution of recorded errors, including: Page URL, User Agent, Script URL, Error Message and Line Number. After each error is resolved, you can Write the solution in one place, and people who see it can comment and add points. It will eventually be archived as a knowledge base, and a convenient API can be used to use the content of these knowledge bases during development and when the same page window.onerror occurs. Through the plug-in, the Error Message is analyzed to identify the type, and the URL is judged to remind developers of the mistakes made by previous developers. Developers can subscribe to certain tags on the knowledge base and automatically receive emails (of course, they can also be based on file comments, mapping, etc. way to make better pairings) Why do you do this? Mainly to solve the following problems: Form a knowledge base from which developers can learn, especially newbie tools to ensure efficiency improvement and avoid repeated errors and repeated solutions. Subscription guarantee notifications are more targeted

3. Notes
1. Use POST to send when collecting. Sometimes the Error Message may be longer, and the URL length of the browser is limited. If there are not many errors saved, you can consider using GET. Send, but generally POST can send all data to the background. 2. When to send data? It is recommended to send data when onerror is triggered. When I first came up with this idea, I tried to send it during onbeforeonload, but the POST request was interrupted by the browser before it was opened. 3. Which index is better to store in the database? Generally speaking, URL may be more suitable for most websites. However, websites with a lot of UGC, such as Baixing.com and Taobao, may need to be modified to record the URL. After all, different posts and different URLs all have the same set of codes. What about using Error as an index? In fact, no matter what kind, choose according to your own needs. 4. Whether to record all errors. This is also more appropriate depending on the needs. There are all kinds of messy error reports on Baidu.com, which may come from ad external links to Baidu/Google.

4. Conclusion
Currently, a collection tool (sofish/stacktrace.js) and storage method have been initially implemented. Whether to continue or not will require time and further consideration. I will send it out first. , throw some bricks and attract jade.