Let's talk in detail about how the NodeJS process exits

Preface

There are several reasons that can cause a NodeJS process to exit. Some of these factors are preventable, such as your code throwing an exception, and some are unpreventable, such as running out of memory. The global variable process is an Event Emitter instance. If the process exits gracefully, process will dispatch an exit event. Application code can listen to this event to do final cleanup.

The following table lists the factors that can cause a process to exit.

Active withdrawal

process.exit(code) is the most direct way to end a process. The code parameter is optional and can be any number between 0 and 255. The default value is 0. 0 indicates that the process is executed successfully, and a non-zero number indicates that the process fails.

When process.exit() is used, there will be no output to the console. If we want to output some error information to the console when the process is exited, we need to display the error information before calling it.

node -e "process.exit(42)"
echo $?

The above code exits the NodeJS process directly, and there is no output information on the command line. When a process exits, users cannot obtain effective error information.

function checkConfig(config) {
  if (!config.host) {
    console.error("Configuration is missing 'host' parameter!");
    process.exit(1);
  }
}

In the code above, we print a clear error message before the process exits.

process.exit() is very powerful, but it should not be used in a utility library. If an error is encountered in the tool library, we should throw it as an exception and let the application code decide how to handle the error.

Exceptions, Rejections and Emitted Errors

process.exit() is very useful in scenarios such as application startup configuration checks, but it is not suitable for handling runtime exceptions and we need other tools.

For example, when an application is processing an HTTP request, an error should not cause the process to terminate. Instead, we should return a response containing an error message.

The Error class can contain data describing the details of the error that occurred, such as the call stack and error text. Usually we will define XXXError for specific scenarios, and these XXXErrors all inherit the Error class.

When we use the throw keyword, or when there is an error in the code logic, an error will be thrown. At this point, the system call stack is unwound and each function is exited until a try/catch statement is encountered that wraps the current call. If there is no try/catch statement, the error is considered an uncaught exception.

Usually, in NodeJS applications, we define a code property for the Error class as an error code to describe the specific error. The advantage of doing so is that the error code can be kept unique and readable. At the same time, we can also use the message attribute to describe the specific error information.

When an uncaught exception is thrown, the call stack is printed to the console and the process exits with an exit status of 1.

/tmp/foo.js:1
throw new TypeError('invalid foo');
^
Error: invalid foo
    at Object.<anonymous> (/tmp/foo.js:2:11)
    ... TRUNCATED ...
    at internal/main/run_main_module.js:17:47

This console output shows that the error occurred at line 2, column 11 in foo.js.

The global variable process is an Event Emitter instance that can handle these uncaught exceptions by listening to the uncaughtException event. The following code shows how to use it:

const logger = require("./lib/logger.js");
process.on("uncaughtException", (error) => {
  logger.send("An uncaught exception has occurred", error, () => {
    console.error(error);
    process.exit(1);
  });
});

Promise Rejection is similar to throwing an exception. We can make a promise reach the rejected state by calling the reject() function or throwing an exception in an async function. The following two code snippets have similar functionality.

Promise.reject(new Error("oh no"));

(async () => {
  throw new Error("oh no");
})();

Currently, in NodeJS 14, Promise Rejection does not cause the process to exit. In subsequent versions, Promise Rejection may cause the process to exit.

Here is some sample console output of an uncaught Promise Rejection.

(node:52298) UnhandledPromiseRejectionWarning: Error: oh no
at Object.<anonymous> (/tmp/reject.js:1:16)
... TRUNCATED ...
at internal/main/run_main_module.js:17:47
(node:52298) UnhandledPromiseRejectionWarning: Unhandled promise
This error originated either by throwing inside of an
async function without a catch block, or by rejecting a promise
which was not handled with .catch().

We can handle uncaught Rejection by listening to the unhandledRejection event. The sample code is as follows:

process.on("unhandledRejection", (reason, promise) => {});

Event Emitter is a basic module in NodeJS and is widely used. When the error event of the Event Emitter is not handled, the Event Emitter will throw an error and cause the process to exit. Below is the console output of an Event Emitter error.

events.js:306
throw err; // Unhandled 'error' event
^
Error [ERR_UNHANDLED_ERROR]: Unhandled error. (undefined)
at EventEmitter.emit (events.js:304:17)
at Object.<anonymous> (/tmp/foo.js:1:40)
... TRUNCATED ...
at internal/main/run_main_module.js:17:47 {
code: 'ERR_UNHANDLED_ERROR',
context: undefined
}

Therefore, when we use Event Emitter, we must make sure to listen to the error event so that when errors occur, the application can handle these errors and avoid crashes.

Signal

Signals are operation messages that provide a mechanism for inter-process communication. A signal is usually a number, but can also be identified by a string. For example, SIGKILL identifies the number 9. Different operating systems define signals differently. The following table lists the basic common signal definitions.

In this table, whether the signal can be processed indicates whether the signal can be received and processed by the process. The NodeJS default behavior indicates the default action that the process performs after receiving this signal.

We can monitor these signals in the following ways.

#!/usr/bin/env node
console.log(`Process ID: ${process.pid}`);
process.on("SIGHUP", () => console.log("Received: SIGHUP"));
process.on("SIGINT", () => console.log("Received: SIGINT"));
setTimeout(() => {}, 5 * 60 * 1000); // keep process alive

Run this code in a command line window and press Ctrl + C. The process will not exit. Instead, a line of log information indicating that a SIGINT signal has been received will be printed in the console. Open a new command line window and execute the following command. PROCESS_ID is the process ID output by the above program.

kill -s SIGHUP <PROCESS_ID>

Through the new command line, we sent a SIGHUP signal to the original program process, and a line of log information indicating that the SIGHUP signal was received will be printed in the original command line window.

In NodeJS code, processes can also send signals to other processes. for example:

node -e "process.kill(<PROCESS_ID>, 'SIGHUP')"

This code will also output a line of log in the first command line window indicating that a SIGHUP signal has been received.

If we want to exit the process of the first command line window, we can do so with the following command.

kill -9 <PROCESS_ID>

In NodeJS, signals are often used to control the graceful exit of the process. For example, in Kubernetes, when a pod is about to exit, k8s sends a SIGTERM signal to the process in the pod and starts a 30-second timer. The application has 30 seconds to close the connection, save data, etc. If the process is still alive after 30 seconds, k8s will send another SIGKILL to force the process to close.

summary

This article describes several factors that can cause a process to exit, namely:

• Active withdrawal
• Uncaught exception, unhandled promise rejection, unhandled Event Emitter error events
• System Signal

This is the end of this article about how to exit the NodeJS process. For more information about NodeJS process exit, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!