It depends on the reason why you're willing to exit node.js process, but in any case process.exit() is the last option to consider. A quote from documentation:
It is important to note that calling
process.exit()will force the process to exit as quickly as possible even if there are still asynchronous operations pending that have not yet completed fully, including I/O operations toprocess.stdoutandprocess.stderr.In most situations, it is not actually necessary to call
process.exit()explicitly. The Node.js process will exit on it's own if there is no additional work pending in the event loop. Theprocess.exitCodeproperty can be set to tell the process which exit code to use when the process exits gracefully.
Let’s cover possible reasons why you might be willing to exit node.js process and why you should avoid process.exit():
Case 1 - Execution complete (command line script)
If script has reached its end and node interpreter doesn't exit, it indicates that some async operations are still pending. It’s wrong to force process termination with process.exit() at this point. It’s better to try to understand what is holding your script from exiting in expected way what is holding your script from exiting in expected way. And when you settle this, you can use process.exitCode to return any result to calling process.
Case 2 - Termination because of external signal (SIGINT/SIGTERM/other)
For example, if you’re willing to gracefully shut down an express app. Unlike command line script, express app keeps running infinitely, waiting for new requests. process.exit() will be a bad option here because it’s going to interrupt all requests which are in pipeline. And some of them might be non-idempotent (UPDATE, DELETE). Client will never know if those requests are completed or not on server side and it might be the reason of data inconsistency between client and server. The only good solution is to tell http server to stop accepting new requests and wait for pending ones to finish with server.close():
var express = require('express');
var app = express();
var server = app.listen(80);
process.on( 'SIGTERM', function () {
server.close(function () {
console.log("Finished all requests");
});
});
If it still doesn't exit - see Case 1.
Case 3 - Internal error
It's always better to throw an error, you’ll get a nicely formatted stack trace and error message. Upper levels of code can always decide if they can handle error (catch) or let it crash the process. On the other side, process.exit(1) will terminate process silently and there will be no chance to recover from this. It might be the only "benefit" of process.exit(), you can be sure that process will be terminated.
It depends on the reason why you're willing to exit node.js process, but in any case process.exit() is the last option to consider. A quote from documentation:
It is important to note that calling
process.exit()will force the process to exit as quickly as possible even if there are still asynchronous operations pending that have not yet completed fully, including I/O operations toprocess.stdoutandprocess.stderr.In most situations, it is not actually necessary to call
process.exit()explicitly. The Node.js process will exit on it's own if there is no additional work pending in the event loop. Theprocess.exitCodeproperty can be set to tell the process which exit code to use when the process exits gracefully.
Let’s cover possible reasons why you might be willing to exit node.js process and why you should avoid process.exit():
Case 1 - Execution complete (command line script)
If script has reached its end and node interpreter doesn't exit, it indicates that some async operations are still pending. It’s wrong to force process termination with process.exit() at this point. It’s better to try to understand what is holding your script from exiting in expected way. And when you settle this, you can use process.exitCode to return any result to calling process.
Case 2 - Termination because of external signal (SIGINT/SIGTERM/other)
For example, if you’re willing to gracefully shut down an express app. Unlike command line script, express app keeps running infinitely, waiting for new requests. process.exit() will be a bad option here because it’s going to interrupt all requests which are in pipeline. And some of them might be non-idempotent (UPDATE, DELETE). Client will never know if those requests are completed or not on server side and it might be the reason of data inconsistency between client and server. The only good solution is to tell http server to stop accepting new requests and wait for pending ones to finish with server.close():
var express = require('express');
var app = express();
var server = app.listen(80);
process.on( 'SIGTERM', function () {
server.close(function () {
console.log("Finished all requests");
});
});
If it still doesn't exit - see Case 1.
Case 3 - Internal error
It's always better to throw an error, you’ll get a nicely formatted stack trace and error message. Upper levels of code can always decide if they can handle error (catch) or let it crash the process. On the other side, process.exit(1) will terminate process silently and there will be no chance to recover from this. It might be the only "benefit" of process.exit(), you can be sure that process will be terminated.
It depends on the reason why you're willing to exit node.js process, but in any case process.exit() is the last option to consider. A quote from documentation:
It is important to note that calling
process.exit()will force the process to exit as quickly as possible even if there are still asynchronous operations pending that have not yet completed fully, including I/O operations toprocess.stdoutandprocess.stderr.In most situations, it is not actually necessary to call
process.exit()explicitly. The Node.js process will exit on it's own if there is no additional work pending in the event loop. Theprocess.exitCodeproperty can be set to tell the process which exit code to use when the process exits gracefully.
Let’s cover possible reasons why you might be willing to exit node.js process and why you should avoid process.exit():
Case 1 - Execution complete (command line script)
If script has reached its end and node interpreter doesn't exit, it indicates that some async operations are still pending. It’s wrong to force process termination with process.exit() at this point. It’s better to try to understand what is holding your script from exiting in expected way. And when you settle this, you can use process.exitCode to return any result to calling process.
Case 2 - Termination because of external signal (SIGINT/SIGTERM/other)
For example, if you’re willing to gracefully shut down an express app. Unlike command line script, express app keeps running infinitely, waiting for new requests. process.exit() will be a bad option here because it’s going to interrupt all requests which are in pipeline. And some of them might be non-idempotent (UPDATE, DELETE). Client will never know if those requests are completed or not on server side and it might be the reason of data inconsistency between client and server. The only good solution is to tell http server to stop accepting new requests and wait for pending ones to finish with server.close():
var express = require('express');
var app = express();
var server = app.listen(80);
process.on( 'SIGTERM', function () {
server.close(function () {
console.log("Finished all requests");
});
});
If it still doesn't exit - see Case 1.
Case 3 - Internal error
It's always better to throw an error, you’ll get a nicely formatted stack trace and error message. Upper levels of code can always decide if they can handle error (catch) or let it crash the process. On the other side, process.exit(1) will terminate process silently and there will be no chance to recover from this. It might be the only "benefit" of process.exit(), you can be sure that process will be terminated.
It depends on the reason why you're willing to exit node.js process, but in any case process.exit() is the last option to consider. A quote from documentation:
It is important to note that calling
process.exit()will force the process to exit as quickly as possible even if there are still asynchronous operations pending that have not yet completed fully, including I/O operations toprocess.stdoutandprocess.stderr.In most situations, it is not actually necessary to call
process.exit()explicitly. The Node.js process will exit on it's own if there is no additional work pending in the event loop. Theprocess.exitCodeproperty can be set to tell the process which exit code to use when the process exits gracefully.
Let’s cover possible reasons why you might be willing to exit node.js process and why you should avoid process.exit():
Case 1 - Execution complete (command line script)
If script has reached its end and node interpreter doesn't exit, it indicates that some async operations are still pending. It’s wrong to force process termination with process.exit() at this point. It’s better to try to understand what is holding your script from exiting in expected way. And when you settle this, you can use process.exitCode to return any result to calling process.
Case 2 - Termination because of external signal (SIGINT/SIGTERM/other)
For example, if you’re willing to gracefully shut down an express app. Unlike command line script, express app keeps running infinitely, waiting for new requests. process.exit() will be a bad option here because it’s going to interrupt all requests which are in pipeline. And some of them might be non-idempotent (UPDATE, DELETE). Client will never know if those requests are completed or not on server side and it might be the reason of data inconsistency between client and server. The only good solution is to tell http server to stop accepting new requests and wait for pending ones to finish with server.close():
var express = require('express');
var app = express();
var server = app.listen(80);
process.on( 'SIGTERM', function () {
server.close(function () {
console.log("Finished all requests");
});
});
If it still doesn't exit - see Case 1.
Case 3 - Internal error
It's always better to throw an error, you’ll get a nicely formatted stack trace and error message. Upper levels of code can always decide if they can handle error (catch) or let it crash the process. On the other side, process.exit(1) will terminate process silently and there will be no chance to recover from this. It might be the only "benefit" of process.exit(), you can be sure that process will be terminated.