-
Notifications
You must be signed in to change notification settings - Fork 18
Better error reporting / handling #20
Comments
If you’re finding the Promises are swallowing up too many errors, a common fix is to change: callingAPromiseFromLibrary().then(function() {
// doSomething
}, function(err) {
// handle the error
}); to: callingAPromiseFromLibrary().then(function() {
// doSomething
}).catch(function(err) {
// handle the error
}); We do this in localForage and it prevents promise errors inside library code (which is what I assume you're hitting) from being "swallowed" by the Promises lib. |
Related: this is probably good practice to convert to anyway, and maybe I can inspect linting code to look for this type of Promise implementation in our code. Users shouldn't have to write promises this way, but our code should. It's mildly annoying at first, when dealing with the otherwise pleasant Promises API, to run into this 😒 |
Yeah, I am using catch in places but the errors are not bubbling up often - because probably the chain of promises is not being returned. I am not sure that linting is going to solve this, it requires looking at the code by a human :-P Also, the second argument to |
Right, but if I understand the chain correctly that means we aren't doing https://github.com/mozilla/node-firefox-connect/blob/master/index.js#L10 That would mean having to wrap the |
While Promises are cool etc they also capture errors in a sneaky way and sometimes it's impossible to find where your error is unless you delve into the code and start console.logging like silly.
For example I was passing a wrong parameter to
connect
and the promise was capturing the error in getWebAppsActor call, which overall remained silent. We should review the flow of each function and make sure errors can bubble up (perhaps intentionally building errors!)This is probably due to my own lack of experience with promises so I accept all fault already :-)
The text was updated successfully, but these errors were encountered: