Difficult to get onPossiblyUnhandledRejection to work all of the time in Node.js due to submodules

[sheltond]

onPossiblyUnhandledRejection sets some global state in the module instance to record the function to call in the event of an unhandled rejection.

However, since npm's default is to install a separate instance of modules in the "node_modules" directory of modules that the app depends on, it's difficult for the app to set up error handling for instances of Bluebird which are referenced from another module.

I came across this with Sequelize - I set up an error handler at the top level in my app, and it usually works fine. However, sometimes the default error handler is used instead. It turned out that this is due to the separate instance of Bluebird that Sequelize is using.

(In fact, certain versions of Sequelize use the sequelize-bluebird module instead, which has some differences, but the same problem applies)

The problem gets worse as your app uses more modules that make use of Bluebird.

I don't really have a good suggested solution, but it seems like this is the sort of thing that an app wants to configure for the entire system, rather than a specific instance of the module.

The only ways that I can really think of to do this is for Bluebird to use some global object in Node.js to co-ordinate the error handling mechanism across the different Bluebird instances. The most likely candidate is the 'process' object, I guess.

For example, this could be done by recording the error handling function in a property of the process object, which would be shared by all Bluebird instances, or by emitting an event on the process object instead of using the onPossiblyUnhandledRejection mechanism, which the app could listen for.

I realise that npm installs modules this way to isolate modules from behavioural changes in their dependencies when other modules in the system have difference versions of the module, but in this case I think it might be worth putting in a 'global' mechanism to set the error handler.

[petkaantonov]

You should be able to work around it by promisifying the callback api of a module through a bluebird instance you control

[petkaantonov]

If a library is using their own private instance, they should expose the hook.

e.g. with sequelize

Sequlize.Promise.onPossiblyUnhandledRejection(function() {
    // Your application specific handler        
});

[benjamingr]

@petkaantonov I think what he's asking for is a way to hook up to every bluebird instance currently running (yours, Sequelize's etc).

That's like adding a:

process.on("bluebirdLoaded", yourHandler); 

And having every instance of bluebird do:

process.emit("bluebirdLoaded", Promise)

When it loads.

[petkaantonov]

But you still need to know about each library specifically whether you can just override their onUnhandledRejection hook, the library might depend on it.

[benjamingr]

@petkaantonov that's true - it might be wise to expose the old handler in the function so:

Promise.onPossiblyUnhandledRejection(function(e, promise, oldHandler) {
    //...
});

Which would let you in turn do:

Promise.onPossiblyUnhandledRejection(function(e, promise, oldHandler) {
    // your own before hooks.
    try{
      var res = oldHandler.apply(this, arguments);
    } catch(e){
         // hook on the library throwing, most likely a rethrow
    } finally {
        // your after hooks here
    }
    return res; // or override, return value isn't used here anyway
});

With a similar parameter for handled possibly unhandled rejections. This might also be useful for adding to the default pretty print behavior.

I don't mind writing a quick PR this weekend if you think this is a good idea. Will help me get acquainted with the code changes anyway.

[petkaantonov]

So when is a good time to fire the onloadedevent so that if the loader were to add a custom hook, the oldHandler would reference it? just setTimeout for the next turn or?

[benjamingr]

Ah, that indeed is an interesting problem to guard against - I'll have a quick look at what bookshelf and a few other libraries do and see if anyone is adding an async unPossiblyUnhandledRejection hook.

Intuition is an async.invoke should definitely be enough - is there any scenario where it'd run after an unhandled rejection is reported?

[petkaantonov]

Btw it could take a long time to get the benefit from this as the older versions obviously don't fire the event.

[petkaantonov]

All unhandled rejections are notified in an invokeLater queue, so async.invoke queue is fine

[petkaantonov]

I really wonder though what a library could possibly do in the handler that it would depend on or couldn't have the application control. What if we just made them global, but allowed multiple listeners, in 3.0.0

[benjamingr]

I'm collecting stats, give me 10 minutes.

[petkaantonov]

I really like

process.on("possiblyUnhandledRejection")
process.on("unhandledRejectionHandled")

• It allows multiple listeners

• It allows the application to remove any custom listeners libraries added

  Like with uncaughtException, if there is not any listener it would only then do the default behavior of console.error (not crash cos it's still only "possible")