JS try-catch statement and error type usage-JS Tutorial-php.cn

This time I will bring you the use of JS try-catch statements and error types. What are the precautions for using JS try-catch statements and error types? The following is a practical case, let's take a look.

Application logic always knows the reason for calling a particular function and is therefore best suited to handle errors. Never leave the catch block in a try-catch empty, you should always write something to handle errors. For example, don't do something like this:

try { somethingThatMightCauseAnError(); } catch (ex) { // do nothing}

Copy after login

If you know an error is likely to occur, you certainly know how to recover from it. Exactly how to recover from errors is different in development mode than actually putting it into production, and that's okay. The most important thing is that you actually deal with the error instead of ignoring it.

The ECMA-262 specification points out 7 error types. These types are used in the JS engine when different error conditions occur, and of course we can also create them manually.

Error: The basic type of all errors. In fact the engine never throws this type of error.

EvalError: Thrown when an error occurs when executing code through the eval() function.

RangeError: Thrown when a number exceeds its bounds - for example, trying to create an array of length -20 (new Array(-20);). This error is very rare in normal code execution.

ReferenceError: Thrown when the expected object does not exist - for example, trying to call a function on a null object reference.

SyntaxError: Thrown when the code has a syntax error.

TypeError: Thrown when the variable is not of the expected type. For example, new 10 or 'prop' in true.

URIError: Thrown when an illegally formatted URI string is passed to functions such as encodeURI(), encodeURIComponent(), decodeURI() or decodeURIComponent().

Understanding the different types of errors can help us deal with it more easily. All error types inherit from Error, so checking their type with instanceof Error will not yield any useful information. Errors can be handled more reliably by checking for specific error types.

try { // 有些代码引发了错误} catch (ex) { if (ex instanceof TypeError) { // 处理TypeError错误 } else if (ex instanceof ReferenceError) { // 处理ReferenceError错误 } else { // 其他处理 } }

Copy after login

If you throw your own error, and it is a data type rather than an error, you can easily distinguish your error from the browser's error type. However, throwing errors of actual types has several advantages over throwing objects of other types.

First, as discussed above, error messages are displayed within the browser's normal error handling mechanism. Secondly, the browser attaches some additional information to the thrown Error object. This information varies from browser to browser, but they provide contextual information for the error such as line and column numbers, and in some browsers also provide stack and source code information. Of course, if you use the Error constructor, you lose the ability to distinguish the errors you throw from browser errors.

The solution is to create your own error type and let it inherit from Error. This approach allows you to provide additional information that is distinct from errors thrown by the browser. Custom error types can be created using the following pattern.

function MyError (message) { this.message = message; } MyError.prototype = new Error();

Copy after login

This code has two important parts: the message attribute, the error message string that the browser must know; setting the prototype to an instance of Error, so that it is identified to the JS engine as an Wrong target. Next, you can throw an instance object of MyError so that the browser can respond like a native error.

throw new MyError('Hello World!');

Copy after login

As a reminder, this method does not display error messages in IE8 and earlier browsers. Instead, you'll see the generic "Exception thrown but not caught" message. The biggest advantage of this method is that custom error types can detect their own errors.

try { // 有些代码引发了错误} catch (ex) { if (ex instanceof MyError) { // 处理自己的错误 } else { // 其他处理 } }

Copy after login

If you always catch all the errors thrown by yourself, then IE's little stupidity will not matter. The benefits gained in a proper error handling system are huge. This method can give more and more flexible information to inform developers how to handle errors correctly.

I believe you have mastered the method after reading the case in this article. For more exciting information, please pay attention to other related articles on the php Chinese website!