An idea for handling JavaScript exceptions

　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

　 It is quite convenient to collect errors, because there is an interface in each browser: window.onerror:

window.onerror = function(errorMessage, scriptURL, lineNumber) {
　 alert (errorMessage, scriptURL, lineNumber)
} even provides Stack Trace. For example, e.stack is also provided in try/catch (each browser is different, you can use the eriwen/javascript-stacktrace compatibility library), try the following Code snippet:

try {
　fn()
} catch(e) {
　alert(e.stack)
} So it is more convenient to collect these errors. What you need to pay attention to here is to use window.addEventListener('error' , callback, isBubble) The first parameter of callback 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 risks of.

　 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 this:

Use URL as a unit to record errors on the same page: to facilitate unified resolution
The recorded errors include: Page URL, User Agent, Script URL, Error Message and Line Number
After each error is resolved , you can write solutions in one place, people who see it can comment and add points, and it will eventually be archived as a knowledge base, and there are convenient APIs to use the content of these knowledge bases
During development, the same page When window.onerror is called, the plug-in is used to analyze the Error Message to identify the type, plus the judgment of the URL, 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 Make better matching based on file comments, mapping, etc.)
Why do you do this? Mainly to solve the following problems:

Form a knowledge base from which developers can learn, especially newcomers
Tools ensure efficiency improvement and avoid repeated mistakes and repeated solutions
Subscription guarantees notifications are more targeted
3. Points to note

　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 stored, you can consider sending it using GET, but generally speaking POST can send all data to the background.

　2. When to send data

　It is recommended to send 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

At present, a collection tool (sofish/stacktrace.js) and storage method (with URL as the index) have been initially implemented. Whether to continue will require time and further consideration. Let’s send it out first to attract more ideas.

　5. Appendix
$url = new Url();
$page = $url->post('page');
if(!$page) return;
class ErrorTrace extends MongoData {
// Not available in MongoData, the difference is
　public function findOne($obj) {
　　return $this->connection->findOne($obj);
　}
};
$store = new ErrorTrace();
$fields = array(
　 'url' => $url->post('url'),
　 'message' => $url->post('message'),
'line' => $url ->post('line'),
　'ua' => $url->post('ua'),
);
$index = array('page' => $page);
$ hash = md5(json_encode($fields));
//Do not record an error repeatedly, all errors are recorded under the same URL
if($field = $store->findOne($index)) {
　if(isset ($field[$hash])) return;
　 return $store->setAttr(new Query('page', $page), $hash, $fields);
}
$store->page = $page ;
$store->$hash = $fields;
$store->save();
?> This Gist brought to you by GitHub.