Difficult to get onPossiblyUnhandledRejection to work all of the time in Node.js due to submodules #357
Comments
|
You should be able to work around it by promisifying the callback api of a module through a bluebird instance you control |
|
If a library is using their own private instance, they should expose the hook. e.g. with sequelize |
|
@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: And having every instance of bluebird do: When it loads. |
|
But you still need to know about each library specifically whether you can just override their onUnhandledRejection hook, the library might depend on it. |
|
@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. |
|
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? |
|
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 Intuition is an |
|
Btw it could take a long time to get the benefit from this as the older versions obviously don't fire the event. |
|
All unhandled rejections are notified in an invokeLater queue, so async.invoke queue is fine |
|
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 |
|
I'm collecting stats, give me 10 minutes. |
|
I really like
|
|
I like it too, just give me a few more minutes to collect data. On Wed, Jan 7, 2015 at 8:36 AM, Petka Antonov notifications@github.com
|
|
Some data from GitHub (NPM data incoming): Ignored people who actually cloned Bluebird's code for this. Large (>1000 stars) libraries typically don't change onPossiblyUnhandledRejection:
Libraries and projects using
|
|
Some conclusions:
|
|
It may also be useful to at least glance at http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/0024.html which we plan on for the browser. I doubt it makes sense to be entirely compatible (since e.g. ErrorEvent is not a thing in Node) but I'd love to make sure the concepts are aligned. Both of them are global handlers ( |
|
@domenic I agree but since in node we are not reusing the |
|
@domenic it seems like this proposal is about logging unhandled rejected promises to @petkaantonov It might be interesting to call |
|
Some more stats, out of all the libraries that are on GH in npm and are dependent on Bluebird:
I think we're ready to go forward with the event emission idea. Let's specify:
|
Yes, thanks, that's what I meant.
Great - that looks like it would solve my problem. |
I would suggest constructing a new |
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.
The text was updated successfully, but these errors were encountered: