JS's try catch Front end usage scenario (though not much still used)

Try{ //normal execute }catch(e/* The type of error you feel will be wrong */) { //////////////////////////) {/////// c11>//can sometimes be used for example focus () but nasty ie may be the first time without the focus event and then let him do it again //Sometimes some bug is not bug on IE he asked for a catch even if an empty catch had encountered this on the IE8 The Egg JS problem }

The use of try catch should always be within your control and should not be protected from unknown errors. In other words, you know that there is a possibility of "error", and you know exactly what the premise will be wrong, you are deliberately using the error message to distinguish errors, the subsequent program will resolve all errors, let the program continue to execute.
If you let the user find a mistake you didn't anticipate, instead of first discovering the error, you are remiss.

In most cases, try catch is suitable for the following situations:

　　　　The occasion of the original sin of the browser

That is, compatibility, because browser compatibility is not the programmer can correct, so can only try catch: due to different browser error prompt is not the same, based on the error prompt of the browser to determine the user's browser, and then make the corresponding measures, this time using try catch is a clever way, If the use if is more clumsy, because if usually only feedback true or false, can not directly feedback the browser error content.

< Span class= "K" > judge code illegality

　　　　WINDOW.A.B is illegal, and comparing with 2 is meaningless, so illegal conditions can continue to run in try catch. However, if the WINDOW.A.B has been an error, the entire page will be broken. If you want to write with if, then you must first determine whether WINDOW.A is legal, WINDOW.A is legitimate under the premise of WINDOW.A.B is not legitimate, if it is legal, and then determine whether WINDOW.A.B is not equal to 2, so is not very stupid? This shows the beauty of Try catch, program not only know WINDOW.A.B!== 2 is false, and directly can know which step is already false.
then imagine that there is a variable is JSON.A.B.C, where the a/b/c may be present or not exist, depending on the situation, this time you simply write if (JSON.A.B.C = = 2) {...} is not possible, because json.a.b may already be illegal, so if you use if, you have to consider whether a is illegal, a is legal premise B is not illegal, B is the legal premise C is not illegal. But json.a.b.c = = 2 in try can write directly, that is, I do not care about the a/b/c who is illegal, I only care about whether JSON.A.B.C is equal to 2, not equal to 2 or any one step error, to me there is no difference, anyway is not equal to 2, I do not care which step error, and the program will not break down. This is a kind of more worry to the wording.

< Span class= "K" > PS: try catch can not be true or false judgment, can only do illegal judgments. That is: try {1 = = 2}, although 1===2 is false, but is legal, catch will not catch the error, will not tell you 1 = = 2 is really false. So, write in the try should be json.a.b.c instead of json.a.b.c = = = 2. is not equal to 2, is behind the matter, is the if dry thing. Simply put, try catch is used to catch an error, and when you don't care about which step is wrong, just care if there is a mistake, use try Catch .

Try {   !== 2}catch(err) {     //  executable     //  Executable }if (window.a.b!== 2) {    alert (//  not executed } Alert (//  do not execute

　　　　It's going to be a change of path.　　

　　　　

Try {    //  execute a logical catch  (e) {    //  problem bird, change logical execution }

　　　　A decent exit　　

Try {  //  normal process catch  (e) {  // pop-up   box tell the user I'm sorry there was something wrong.   //   If it is the user's fault to tell the user what is wrong  //   If the program is wrong, Just tell the user I'm sorry, I can't execute }

Write at the end:

　　

Exception handling and error handling are two different concepts. For example, most errors in Nodejs are used to handle exceptions, because exceptions are unavoidable, such as database hangs, network errors, though you know it is possible, but you do not know when, these anomalies you need to capture or pass to the top. Error handling, is a basic decision, you can avoid it from the code level, predictable can be inferred, if it happens, is not a system problem, but your program has a bug.

For Nodejs, both errors need to be noticed at all times, especially system errors, because unpredictable, requiring a lot of code to catch errors, pass errors, and finally unify processing.

For the front end, the system errors appear relatively much lower, mainly some IO scenes, most of the front end may not be too concerned. and ordinary error handling, it is more common, because the front-end coupling of the specific system more, and these system operations, the data and dom what is mostly predictable, with the system error or to distinguish between the open, some errors, you need to swallow and deal with, if there is an error, is obviously a bug, not unpredictable.

JS's try catch Front end usage scenario (though not much still used)