feature request - callbacks in exit handlers - to block even if async code is used

[ORESoftware]

I'm on the latest version of Node (6.7)

I have been using Node for awhile and one thing that seems to be a missing feature is shutdown hooks that are "blocking", even if they feature async code. To "block" in this case would require callbacks. A simple use-case is a child_process that needs to use process.send() (with a request/reply) pattern with a parent process. process.send() is async, and so we can't be guaranteed the parent process will receive the message before the parent may exit.

for example what we have now is this ('beforeExit' might be deprecated or gone by now):

process.on('beforeExit', function () {

});

process.on('exit', function (code, signal) {

});

what I am looking for is this type of functionality:

process.on('beforeExit', function (cb) {
         setTimeout(cb, 3000);
});

process.on('exit', function (err, code, signal) {
        // if 'beforeExit' handler is in place, then this will only be called when the callback fires
        // in the beforeExit handler
});

does this functionality exist? The temporary solution is to simply put blocking code in these handlers, but that's not always idea. Hope this makes sense :) I believe it's possible to do this just wondering if it is a sensible request.

The use case is I have programs which need to run shutdown hooks even if there is a fatal exception in the code, these shutdown hooks have asynchronous code by nature (process.send, for one). So it's a feature that I really need.

[mscdex]

If there is an unhandled exception, you can register a listener for that which will prevent node from exiting by default:

process.on('uncaughtException', function(err) {
  console.log('Uncaught exception: ' + err.stack);
  // Call shutdown hooks and then exit manually
});

[ORESoftware]

that might solve the problem, not sure why it didn't occur to me, let me think about it for a bit

[bnoordhuis]

The use case is I have programs which need to run shutdown hooks even if there is a fatal exception in the code,

That's a terrible idea in general. If you have an unexpected exception then by definition your program is in an undefined state. The documentation for the uncaughtException event is very clear that trying to continue, or simply staving off program exit, is a recipe for unpredictable behavior.

[Fishrock123]

It may be more useful to check to see when the process dies and do external cleanup from another application.

[ORESoftware]

@bnoordhuis this is for a test framework/library. Errors thrown from test cases may reach the uncaughtException handler. Testing inverts the software development process a bit, because thrown errors are more expected. So in this case, the user/dev will have shutdown hooks that should always run, even if an uncaughtException occurs. Upon an uncaughtException, the test process(es) will exit with a value greater than zero no matter what, that's all that matters in this case. Seen?

My current belief is that it would be simply convenient to have the functionality I am looking for, but that uncaughtException handlers will solve the problem, just less conveniently. You can close this if you want :)

[bnoordhuis]

Upon an uncaughtException, the test process(es) will exit with a value greater than zero no matter what

You don't need an uncaughtException listener in order to exit with a non-zero status code, node does that by default.

I'll go ahead and close the issue.

[ORESoftware]

Upon an uncaughtException, the test process(es) will exit with a value
greater than zero no matter what

You don't need an uncaughtException listener in order to exit with a
non-zero status code, node does that by default.

....yes but I need the uncaughtException handler to do asynchronous
cleanup, the original purpose of the question :)
On Oct 19, 2016 2:57 AM, "Ben Noordhuis" notifications@github.com wrote:

Closed #9090 #9090.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#9090 (comment), or mute the
thread
https://github.com/notifications/unsubscribe-auth/AKn56MFFl6HY4CfPvbkQN3nsMJmjg2jPks5q1el-gaJpZM4KWdcT
.

[ORESoftware]

furthermore, I define special exit codes depending on the nature of the
error - it's excellent for debugging...another reason for uncaughtException
handler...
On Oct 19, 2016 9:19 AM, "Alexander Mills" alex@oresoftware.com wrote:

Upon an uncaughtException, the test process(es) will exit with a value
greater than zero no matter what

You don't need an uncaughtException listener in order to exit with a
non-zero status code, node does that by default.

....yes but I need the uncaughtException handler to do asynchronous
cleanup, the original purpose of the question :)
On Oct 19, 2016 2:57 AM, "Ben Noordhuis" notifications@github.com wrote:

Closed #9090 #9090.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#9090 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AKn56MFFl6HY4CfPvbkQN3nsMJmjg2jPks5q1el-gaJpZM4KWdcT
.