do we need process.exit(1) when we use promises in node.js

Question

In our company we are having a discussion of sorts regarding whether we need exit a process in the event of an unhandled exception in node.js while using promises

Two schools of thoughts have been playing on my mind

• when we use promises in node.js we need to use process.exit(1)

• we don't need to use process.exit(1) when we use promises

By the way we are planning to use the blubird module for promises.

https://www.npmjs.org/package/bluebird

I want to know whether its necessary to exit the process in the event of an unhandled exception as while using promises we get "finally" statement to cleanup the resources

http://canop.org/blog/?p=516

Also what types of errors can we expect when it comes to node.js that promises might not be able to handle by itself, if there are any, which we might need to handle via

process.on("uncaughtException")
{
process.exit(1);
}

Answer 1

Short answer, no.

Long answer:

When you call process.exit() you cause processing to stop. The exit event is fired, which is the last opportunity for any code to run, and the event loop is stopped. Shortly thereafter Node.js actually stops completely and returns the specified exit code. So process.exit() stops Node.js from doing anything tangible after that point and the application stops.

The problem

The problem is that process.exit() can be called by any part of the application at any time. There is nothing preventing a parser from calling it:

exports.parse = function(text) {

    if (canParse(text)) {
        return doTheParse(text);
    } else {
        console.error("Can't parse the text.");
        process.exit(1);
    }

};

So if the text can be parsed then it is, but otherwise an error is output to the console and process.exit(1) is called. That’s an awful lot of responsibility for a lowly parser.

Since any module can call process.exit(), that means any function call gone awry could decide to shut down the application. That’s not a good state to be in. There should be one area of an application that decides when and if to call process.exit() and what the exit code should be (that’s usually the application controller). Utilities and such should never use process.exit(), it’s way out of their realm of responsibility.

Anytime you’re thinking about using process.exit(), consider throw an error instead:

Throwing an error has a similar effect as calling process.exit() in that code execution in this function stops immediately. However, calling functions have the opportunity to catch the error and respond to it in a graceful manner. If there is no intervention up the call stack, then the uncaughtException event is fired on process. If there are no event handlers, then Node.js will fire the exit event and exit with a non-zero exit code just like when process.exit() is called; if there are event handlers, then it is up to you to manually call process.exit() to specify the exit code to use.

The key is that throwing an error gives the application an opportunity to catch the error and recover from it, which is almost always the desired case when dealing with module code.

source: here

Answer 2

.finally is not very good for resource management:

• It can be forgotten and only a careful audit can find forgotten cleanups
• It can subtly leak resources in more complicated scenarios

That's why 2.0 introduced using, it's virtually impossible to forget to use it because a promise for resource is actually a disposer which can only be used with using.

So if you acquire your resources with using, there is no need to restart from the errors that happen within.

Note that this doesn't cover bugs in libraries, if you are using a library that leaks resources then you need to restart your process. For example there is nothing you can do about https://github.com/joyent/node/issues/7697 (except fork node and use promises in core so this kind of thing is impossible :D).