Due to network, browser and cache issues, the JS executed in production may produce different results from the testing environments. Sometimes they may produce exceptions. Front-end developers may encounter this kind of exceptions frequently. But how to log and use them is seldomly considered by them. Actually, exception handling includes two steps : log and use.
1. Log
Regarding to log error, this is relatively convenient, since in each browser, there is one interface called window.onerror.
window.onerror =function(errorMessage, scriptURL, lineNumber){ alert(errorMessage, scriptURL, lineNumber)}
It also provides stack trace, for example try/catch provides e.stack(different browsers have different implementations, you can use eriwen/javascript-stacktrace ),try to use below codes:
try{ fn()}catch(e){ alert(e.stack)}
Here one thing to note is when using window.addEventListener('error',callback,isBubble), the first parameter of callback is not event but an Error object. For convenience, it's a good idea to use window.onerror.
2. Use
When JS code produces error, it may send a mail to the front end development team, each developer will know the erroris for him and go to fix it. In fact this is a good choice and it also solves a basic problem: immediate response and fix. There is one more issue using this method. How to avoid this same error? My initial thought like this:
- Categorize them with URL, log all the errors in one page at the same place.
- Errors to record include : Page URL,User Agent,Script URL,Error Message and Line Number.
- After each error is fixed, we can write all the solutions at the same place, people who see them can comment, support them And finally this document will be saved.
- In development, we can use plug ins to analyze the Error Message and know which type it is.
- Developers can subscribe to some types of errors and receive emails automatically.
Why we should do these?
- To have a knowledge base so that developers can learn from them, especially for new joiners.
- Tools can ensure the improvement of efficiency and avoid repeated errors
- Subscribe to error notification.
3. Notes
1. Using POST method to log
Sometimes Error Message will be very long, but web browsers can accept only limited length of URL, so if you don't store many errors, you can consider to use GET, but usually POST can be used to send all the data to the backend.
2. When to send the data
Suggest you send the data when onerror is triggered.
3. Which field to be indexed in the database
Usually we can use URL to be the index. But you can choose which one to use depending on your actual needs.
4 Conclusion
Here we implement a logging tool sofish/stcktrace.js. Just as an introduction.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
<?php $url = new Url();$page = $url->post('page'); if(!$page) return; class ErrorTrace extends MongoData { 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)); 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(); ?> |
Source : http://sofish.de/2144
