Shulou(Shulou.com)06/03 Report--

Editor to share with you an example of Node error handling analysis, I believe that most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to understand it!

01 Error

The Error object in JS contains specific information about the error, including name, message, error stack stack, and so on. You can create an instance throw in new Error, or call Error.captureStackTrace to add stack error stack information to an existing object and then throw it.

02 error thrown in several ways

* the exceptions thrown by Throw*:Javascript are thrown in the throw method, and they may not be instances of Error, but the errors that occur when running through nodeJs or js are all instances of Error.

* error callback in the form of EventEmitter*:Nodejs. Most stream-asynchronous events are derived from EventEmitter class | | instances, such as fs, process, stream, etc.

Process: exceptions thrown while the program is running, either thrown by the underlying library, or some SyntaxError that occurs while running.

03 several ways of error capture

Try.. Catch: a commonly used way to catch errors, browser | | node environment is applicable.

Cons: effective only for synchronization exceptions.

* EventEmitter *

The EventEmitter class provided by the Events module, publish/subscribe based on Observer mode, via .on ('error',...) | .addEventlistener (' error',...) Register the subscriber,.emit () publish event, but there will be maximum maxListener restrictions that can be changed.

No show source code, it's very simple, go to look yourself. For example, koa's app is an extension based on EventEmitter, so you can listen to error.

* Process *

The Process process object is also an instance of EventEmitter, and you can listen to error through the following two events.

UnhandledRejection: the callback of promise reports an error. You can listen to the event catch, but note that since the rejection of promise does not know when it will occur, you may actually catch this information after the unhandledRejection event is triggered. You should listen to the rejectionHandled event as follows:

UncaughtException: the uncaptured errors thrown during the rest of the js run | | can be solved by listening to the event. If the event is not listened to, an exception will directly cause the program crash. But it is not recommended to use this way of catch, the error in the operation of the program should be thrown out, if all the error are catch, the program can be regarded as no bug. But needs catch to report the error log when typing the error log, but after the report, you need to continue to send the error throw. The exception thrown in the uncaughtException callback will no longer be caught, but exit with a status code of non-0.

04 summary

Having said so much, let's make a little summary. The above network can be summarized as follows:

Personal opinion, the actual handling is based on several criteria:

1. For the error message that needs to be materialized, that is, we need to know which part of the error it is, and personalize it when the error occurs. For this type of error, when executing in the program, you need to catch the functions that may go wrong in a variety of ways: try. Catch (synchronization); or through the standard error callback (err) in the form of node (err) > {...} (requires the called method to support this writing), or listens to the error event .on ('error', err = > {...}) (requires the called object to inherit from the EventEmitter instance and emit (' error') when an internal error occurs).

2. Errors in the form of promise, .catch can be introduced at the end of the promise instance to catch exceptions thrown in all then of the instance; in addition, the introduction of async also allows us to catch errors like synchronous operations.

3. But sometimes when the program is running, it is impossible to try all the function operations. Catch, there is no guarantee that the program will run without bug, but it must be able to catch and report these exceptions. Therefore, the two big boss of process, unhandledRejection & uncaughtException, must be introduced in the outermost layer of the program, and the farther forward the better. In addition, for unhandledRejection, in order to prevent unnecessary rejection reporting, you can first store the promise and error of the reject when you receive the event, set the time maxTimeout, and then report the promise event that has not been received by rejectionHandled beyond maxTimeout.

The koa project is an example:

05 source code interpretation

The following figure shows a series of processes such as initialization of process in node:

Node.cc is actually the main file that node runs, in which three overloaded functions Start are defined, the calling order is 3 → 2 → 1, and each function parameter handles different logic.

The listening event OnMessage for isolate- > AddMessageListener triggers when there is an error in the js run, well, yes, only error can pass it; this explains why process listens to uncaughtException to listen for all thrown non-promise exceptions

OnMessage calls the FatalException function, and FatalException refers to process.fatalException and passes error (env is the instance of Environment class declared in env.h, where fatalexceptionstring is also defined, and the return value is' fatalException'). The following is part of the FatalException function.

Before calling the fatalException function, call v8::TryCatch::setVerbose to set verbose to false, then the exception thrown at runtime will no longer trigger FatalException; after catching the run error, set exitcode to 7 and return; this explains why the exception thrown in uncaughtException will not trigger the callback again, knowing that EventEmitter does not do such a thing for you.

_ fatalException will first check whether domain exists before triggering the "uncaughtException" event, and uncaughtException will only be called when domain does not exist, but domain has been abolished, so it will not be repeated.

The overall idea of triggering unhandledRejection events is similar, first calling SetupPromises initialization, and then calling v8::Isolate::SetPromiseRejectCallback to listen. And unlike uncaughtException, the trigger of unhandledRejection only prints warning and does not give the whole program to crash.

The above is all the contents of the article "sample Analysis of Node error handling". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.