Once a promise reject() callback is called, a warning message "Uncaught (in promise)" appears in the Chrome console. I can't wrap my head around the reason behind it, nor how to get rid of it.
var p = new Promise((resolve, reject) => {
setTimeout(() => {
var isItFulfilled = false
isItFulfilled ? resolve('!Resolved') : reject('!Rejected')
}, 1000)
})
p.then(result => console.log(result))
p.catch(error => console.log(error))
Warning:
Edit:
I found out that if the onRejected handler is not explicitly provided to the .then(onResolved, onRejected) method, JS will automatically provide an implicit one. It looks like this: (err) => throw err. The auto generated handler will throw in its turn.
Reference:
If IsCallable(onRejected)` is false, then
Let onRejected be "Thrower".
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-performpromisethen
This happens because you do not attach a catch handler to the promise returned by the first then method, which therefore is without handler for when the promise rejects. You do have one for the promise p in the last line, but not for the chained promise, returned by the then method, in the line before it.
As you correctly added in comments below, when a catch handler is not provided (or it's not a function), the default one will throw the error. Within a promise chain this error can be caught down the line with a catch method callback, but if none is there, the JavaScript engine will deal with the error like with any other uncaught error, and apply the default handler in such circumstances, which results in the output you see in the console.
To avoid this, chain the .catch method to the promise returned by the first then, like this:
p.then( result => console.log('Fulfilled'))
.catch( error => console.log(error) );
Even if you use Promises correctly: p.then(p1).catch(p2) you can still get an uncaught exception if your p2 function eventually throws an exception which you intend to catch using a mechanism like window.onerror. The reason is that the stack has already been unwound by the error handling done in the promise. To fix this, make sure that your error code (called by the reject function) does not throw an exception. It should simply return.
It would be nice if the error handling code could detect that the stack has already been unwound (so your error call doesn't have to have a flag for this case), and if anyone knows how to do this easily I will edit this answer to include that explanation.
This code does not cause the "uncaught in promise" exception:
// Called from top level code;
// implicitly returns a Promise
testRejectCatch = async function() {
// Nested within testRejectCatch;
// simply rejects immediately
let testReject = function() {
return new Promise(function(resolve, reject) {
reject('test the reject');
)};
}
//***********************************************
// testRejectCatch entry.
//***********************************************
try {
await testReject(); // implicitly throws reject exception
catch(error) {
// somecode
}
//***********************************************
// top level code
//***********************************************
try{
testRejectCatch() // Promise implicitly returned,
.catch((error) => { // so we can catch
window.alert('Report error: ' + error);
// must not throw error;
});
}
catch(error) {
// some code
}
Explanation:
First, there's a terminology problem. The term "catch" is
used in two ways: in the try-catches, and in the Promises.
So, it's easy to get confused about a "throw"; is it throwing
to a try's catch or to a Promise's catch?
Answer: the reject in testReject is throwing to the Promise's
implicit catch, at await testReject; and then throwing on to
the .catch at testRejectCatch().
In this context, try-catch is irrelevant and ignored;
the throws have nothing to do with them.
The .catch at testRejectCatch satisfies the requirement
that the original throw must be caught somewhere,
so you do not suffer the "uncaught in Promise..." exception.
The takeaway: throws from Promises are throws to .catch,
not to try-catch; and must be dealt-with in some .catch
Edit:
In the above code, the reject propagates up through the .catches.
If you want, you can convert over to propagating up the try-catches.
At line 17, change the code to:
let bad = '';
await testReject().catch((error) => {bad = error});
if (bad) throw bad;
Now, you've switched over to the try-catch.
I ran into this issue, but without setTimeout().
In case anyone else runs into this: if in the Promise constructor you just call reject() synchronously, then it doesn't matter how many .then() and .catch() handlers you add to the returned Promise, they won't prevent an uncaught promise rejection, because the promise rejection would happen before you
I've solved that problem in my project, it's a large enterprise one. My team is too lazy to write empty catch hundreds of times.
Promise.prototype.then = function (onFulfilled, onRejected) {
return baseThen.call(this, (x: any) => {
if (onFulfilled)
onFulfilled(x);
}, (x: any) => {
if (onRejected)
onRejected(x);
});
};
Related
Edit:
Promises do not hide exceptions, as was pointed out by the excellent (accepted) answer. I want to elaborate on how exceptions in promises were invisible:
I was working on a project that used a propriatary library to make ajax calls. Now in case something in the callback of the ajax-call went wrong an exception would be thrown. This exception would then trigger the reject() to be called, which was then silently discarded. In fact the exceptions were not hidden, but actively disposed of further down the code in an empty error-callback. This ultimatly led to a situation where it was very difficult to even recognize that an error had occured.
Here the original question:
I know that I can add a catch-block to all my promises and console.log the error there. In my usecase I need to catch the exceptions at a higher level up the call-stack.
http://jamesknelson.com/are-es6-promises-swallowing-your-errors/
Here in another question on SO, the accepted answer also proposes catch-blocks:
Catching errors generated in Promises within Promises in JavaScript
Javascript silently swallows Exceptions that are thrown within a Promise.
No, it doesn't. An exception thrown in a promise executor (the function you pass new Promise) or a then/catch handler is used as the value of the rejection of the promise. Any decent implementation will also log a console error if you have unhandled rejections. For instance, try this in a recent version of Chrome or Firefox:
new Promise(() => { throw new Error("Unhandled"); })
In the console you'll find:
Uncaught (in promise) Error: Unhandled
at Promise (js:13)
at new Promise ()
at js:13
Soon, NodeJS will start terminating the process on unhandled rejections just like unhandled exceptions. Because rejections are exceptions.
I do not want to add a catch-block to all my promises.
You don't have to. The rule of promises is you either return the promise or handle rejections from it; almost never both. (You'd do both only rarely, such as when you're "wrapping" the error that occurred to make it more high-level.) So you only need a catch on promises that you don't propagate to the caller. Best practice is to propagate to the highest level you can and then handle them there. Most of the time you don't write a catch because you're propagating the promise.
Can I monkey-patch (or else) the native Promises in such a way that they stop hiding my exceptions?
Well, again, they don't. You can replace Promise and Promise.prototype.then so they report exceptions to the console, but you'll end up reporting things that are handled by subsequent handlers and shouldn't be reported. For example:
// NOT RECOMMENDED
const RealPromise = Promise;
Promise = class Promise extends RealPromise {
constructor(executor) {
super((resolve, reject) => {
try {
executor(resolve, reject);
} catch (e) {
console.error(e);
reject(e);
}
});
}
then(onResolved, onRejected) {
return super.then(val => {
try {
return onResolved(val);
} catch (e) {
console.error(e);
throw e;
}
}, onRejected);
}
};
new Promise(() => {
throw new Error("Handled");
}).catch(e => {
console.log("But I handled it!");
});
...but it wouldn't be a good idea, as you can see.
If you follow the propagate-or-handle rule, you should be fine with built-in promises.
It's also probably worth noting async/await syntax, which are new as of ES2017: When using async/await, promise rejection values are used as exceptions, closing the circle:
function foo() {
return new Promise((resolve, reject) => {
setTimeout(reject, 500, "Failed");
});
}
(async () => {
try {
await foo();
} catch (e) {
console.log("Got error: ", e);
}
})();
In browsers, you can listen to the unhandledrejection event that is emitted for uncaught rejected promises:
window.addEventListener('unhandledrejection', function(event) {
event.preventDefault();
// the reject value is available as event.reason
console.error("Promise was rejected with reason:", event.reason);
});
Promise.reject("something");
This applies both to native promises and some Promise libraries (such as Bluebird).
The below code doesn't handle error though condition is satisfied. Please help understand why
Edit:the below code now terminates code flow in case of satisfying condition but throwing a error result in unhandled rejection.
utils.js
const isMaximum = Id => {
return db.Entries
.findAndCountAll()
.then(counts => {
let numberOfEntries = 2;
let maxEntries = 2;
if (numberOfEntries == maxEntries) {
return true;
}
else{
return false;
}
});
};
xyz.js
const doSomething=(req,res,next)=>{
Utils.isMaximum(id).then(isLimit=> {
if(isLimit) throw new Error("not allowed"); //unhandled rejection
//rest of code gets terminated as expected
});
}
Related questions Why can I not throw inside a Promise.catch handler? couldn't find me a solution. So please make it clear.
Throwing inside a .catch() handler makes the promise chain a rejected promise. If you don't have a subsequent .catch() handler, then it will get reported as an unhandled promise rejction because you have no .catch() afterwards to catch the rejected promise. This is nearly always a programming error which is why you get the warning.
Throwing inside a .catch() does not terminate your program. That exception is caught by the promise infrastructure (and turned into a rejected promise). That's how promises work (by specification). If you want your program to terminate at that point, then you can call process.exit() rather than throwing.
Now you've edited your question and now you're trying to throw inside a .then() handler. OK. I'll address what you've added. Next time please start with the whole code context so we can more quickly understand the situation.
Utils.isMaximum() is asynchronous. It returns a promise. You need to program with using asynchronous techniques. You can't think like synchronous sequential code. Any code that comes after your call to Utils.isMaximum() will execute BEFORE the .then() handler is called.
Here's a simple example:
Utils.isMaximum(id).then(isLimit => {
console.log("A");
});
console.log("B");
That will output:
B
A
So, for starters, you can't prevent the code that comes after the .then() block from running by anything you do inside the .then() block because the rest of the function executes BEFORE the .then() handler does.
So, the usual way you deal with that is you have to put the rest of the code INSIDE the .then() handler or inside a function you call from there:
const doSomething=(req,res,next)=>{
Utils.isMaximum(id).then(isLimit=> {
if(!isLimit){
// rest of code here that sends regular response
} else {
// handle error here - send error response
// or OK to throw here, throw will be caught by next .catch()
}
}).catch(err => {
// send error response here
});
}
I didn't catch the error I throw and that is the only reason why. Below resolved.
const doSomething=(req,res,next)=>{
Utils.isMaximum(id).then(isLimit=> {
if(isLimit) throw new Error("not allowed");
}).catch(next);
//rest of code gets terminated as expected
}
I had a look at the bluebird promise FAQ, in which it mentions that .then(success, fail) is an antipattern. I don't quite understand its explanation as for the try and catch.
What's wrong with the following?
some_promise_call()
.then(function(res) { logger.log(res) }, function(err) { logger.log(err) })
It seems that the example is suggesting the following to be the correct way.
some_promise_call()
.then(function(res) { logger.log(res) })
.catch(function(err) { logger.log(err) })
What's the difference?
What's the difference?
The .then() call will return a promise that will be rejected in case the callback throws an error. This means, when your success logger fails, the error would be passed to the following .catch() callback, but not to the fail callback that goes alongside success.
Here's a control flow diagram:
To express it in synchronous code:
// some_promise_call().then(logger.log, logger.log)
then: {
try {
var results = some_call();
} catch(e) {
logger.log(e);
break then;
} // else
logger.log(results);
}
The second log (which is like the first argument to .then()) will only be executed in the case that no exception happened. The labelled block and the break statement feel a bit odd, this is actually what python has try-except-else for (recommended reading!).
// some_promise_call().then(logger.log).catch(logger.log)
try {
var results = some_call();
logger.log(results);
} catch(e) {
logger.log(e);
}
The catch logger will also handle exceptions from the success logger call.
So much for the difference.
I don't quite understand its explanation as for the try and catch
The argument is that usually, you want to catch errors in every step of the processing and that you shouldn't use it in chains. The expectation is that you only have one final handler which handles all errors - while, when you use the "antipattern", errors in some of the then-callbacks are not handled.
However, this pattern is actually very useful: When you want to handle errors that happened in exactly this step, and you want to do something entirely different when no error happened - i.e. when the error is unrecoverable. Be aware that this is branching your control flow. Of course, this is sometimes desired.
What's wrong with the following?
some_promise_call()
.then(function(res) { logger.log(res) }, function(err) { logger.log(err) })
That you had to repeat your callback. You rather want
some_promise_call()
.catch(function(e) {
return e; // it's OK, we'll just log it
})
.done(function(res) {
logger.log(res);
});
You also might consider using .finally() for this.
The two aren't quite identical. The difference is that the first example won't catch an exception that's thrown in your success handler. So if your method should only ever return resolved promises, as is often the case, you need a trailing catch handler (or yet another then with an empty success parameter). Sure, it may be that your then handler doesn't do anything that might potentially fail, in which case using one 2-parameter then could be fine.
But I believe the point of the text you linked to is that then is mostly useful versus callbacks in its ability to chain a bunch of asynchronous steps, and when you actually do this, the 2-parameter form of then subtly doesn't behave quite as expected, for the above reason. It's particularly counterintuitive when used mid-chain.
As someone who's done a lot of complex async stuff and bumped into corners like this more than I care to admit, I really recommend avoiding this anti-pattern and going with the separate handler approach.
By looking at advantages and disadvantages of both we can make a calculated guess as to which is appropriate for the situation.
These are the two main approaches to implementing promises. Both have it's pluses and minus
Catch Approach
some_promise_call()
.then(function(res) { logger.log(res) })
.catch(function(err) { logger.log(err) })
Advantages
All errors are handled by one catch block.
Even catches any exception in the then block.
Chaining of multiple success callbacks
Disadvantages
In case of chaining it becomes difficult to show different error messages.
Success/Error Approach
some_promise_call()
.then(function success(res) { logger.log(res) },
function error(err) { logger.log(err) })
Advantages
You get fine grained error control.
You can have common error handling function for various categories of errors like db error, 500 error etc.
Disavantages
You will still need another catch if you wish to handler errors thrown by the success callback
Simple explain:
In ES2018
When the catch method is called with argument onRejected, the
following steps are taken:
Let promise be the this value.
Return ? Invoke(promise, "then", « undefined, onRejected »).
that means:
promise.then(f1).catch(f2)
equals
promise.then(f1).then(undefiend, f2)
Using .then().catch() lets you enable Promise Chaining which is required to fulfil a workflow. You may need to read some information from database then you want to pass it to an async API then you want to manipulate the response. You may want to push the response back into the database. Handling all these workflows with your concept is doable but very hard to manage. The better solution will be then().then().then().then().catch() which receives all errors in just once catch and lets you keep the maintainability of the code.
Using then() and catch() helps chain success and failure handler on the promise.catch() works on promise returned by then(). It handles,
If promise was rejected. See #3 in the picture
If error occurred in success handler of then(), between line numbers 4 to 7 below. See #2.a in the picture
(Failure callback on then() does not handle this.)
If error occurred in failure handler of then(), line number 8 below. See #3.b in the picture.
1. let promiseRef: Promise = this. aTimetakingTask (false);
2. promiseRef
3. .then(
4. (result) => {
5. /* successfully, resolved promise.
6. Work on data here */
7. },
8. (error) => console.log(error)
9. )
10. .catch( (e) => {
11. /* successfully, resolved promise.
12. Work on data here */
13. });
Note: Many times, failure handler might not be defined if catch() is
written already.
EDIT: reject() result in invoking catch() only if the error
handler in then() is not defined. Notice #3 in the picture to
the catch(). It is invoked when handler in line# 8 and 9 are not
defined.
It makes sense because promise returned by then() does not have an error if a callback is taking care of it.
Instead of words, good example. Following code (if first promise resolved):
Promise.resolve()
.then
(
() => { throw new Error('Error occurs'); },
err => console.log('This error is caught:', err)
);
is identical to:
Promise.resolve()
.catch
(
err => console.log('This error is caught:', err)
)
.then
(
() => { throw new Error('Error occurs'); }
)
But with rejected first promise, this is not identical:
Promise.reject()
.then
(
() => { throw new Error('Error occurs'); },
err => console.log('This error is caught:', err)
);
Promise.reject()
.catch
(
err => console.log('This error is caught:', err)
)
.then
(
() => { throw new Error('Error occurs'); }
)
I'm a bit confused about when an error in a promise is passed to the catch handler.
With the following bit of code, if promise2 causes an error, is that passed to the catch at the bottom? Also, does my return inside the first "then" return promise2 as a promise, or does it return doc.
promise1(foo).then(doc =>{
return promise2(doc).then(doc => {
return doc
})
}).then(doc =>{
console.log(doc)
}).catch(err => {
console.error(err)
})
Cheers
A then can return a promise, but if something fails you need to explicitly return a reject. In the example below changedDoc is passed to the second then as newDoc
promise1(foo).then(doc =>{
// changedDoc = doc.....
if (good things happened) {
return changedDoc;
} else {
return new Promise.reject("error");
}
}).then(newdoc =>{
console.log(newdoc)
}).catch(err => {
console.error(err)
})
then can receive two parameters:
one for the case when the promise is fulfilled
other for the case when the promise is rejected (purposefully, or because an exception was thrown)
If there is an error in the execution of the code, either in the fullfilled, or the rejected, the execution will continue in the next rejected callback. In your code the first rejected callback, is the one specified in the catch callback. If that block didn't exist, the exception would keep bubbling up to the first catch block in the code. And, if there was no such block, it would be handled by the browser, and shown as an error to the user.
If you look at the documentation, you'll see that catch is just like a then that receives only the second parameter:
Promise.prototype.then(onFulfilled, onRejected)
Promise.prototype.catch(onRejected)
You can also have a look at this documentation on handling exceptions with promises.
The whole idea of promises is being able to chain then, so that the succes is propagated to the onFullfilled callback, which can run without error, and return something for the next onFullfilled handler, or run with error, with will be handled by the next onRejected. The error can be a purposefull rejection, or an unhandled exception.
Why can't I just throw an Error inside the catch callback and let the process handle the error as if it were in any other scope?
If I don't do console.log(err) nothing gets printed out and I know nothing about what happened. The process just ends...
Example:
function do1() {
return new Promise(function(resolve, reject) {
throw new Error('do1');
setTimeout(resolve, 1000)
});
}
function do2() {
return new Promise(function(resolve, reject) {
setTimeout(function() {
reject(new Error('do2'));
}, 1000)
});
}
do1().then(do2).catch(function(err) {
//console.log(err.stack); // This is the only way to see the stack
throw err; // This does nothing
});
If callbacks get executed in the main thread, why does the Error get swallowed by a black hole?
As others have explained, the "black hole" is because throwing inside a .catch continues the chain with a rejected promise, and you have no more catches, leading to an unterminated chain, which swallows errors (bad!)
Add one more catch to see what's happening:
do1().then(do2).catch(function(err) {
//console.log(err.stack); // This is the only way to see the stack
throw err; // Where does this go?
}).catch(function(err) {
console.log(err.stack); // It goes here!
});
A catch in the middle of a chain is useful when you want the chain to proceed in spite of a failed step, but a re-throw is useful to continue failing after doing things like logging of information or cleanup steps, perhaps even altering which error is thrown.
Trick
To make the error show up as an error in the web console, as you originally intended, I use this trick:
.catch(function(err) { setTimeout(function() { throw err; }); });
Even the line numbers survive, so the link in web console takes me straight to the file and line where the (original) error happened.
Why it works
Any exception in a function called as a promise fulfillment or rejection handler gets automatically converted to a rejection of the promise you're supposed to return. The promise code that calls your function takes care of this.
A function called by setTimeout on the other hand, always runs from JavaScript stable state, i.e. it runs in a new cycle in the JavaScript event loop. Exceptions there aren't caught by anything, and make it to the web console. Since err holds all the information about the error, including the original stack, file and line number, it still gets reported correctly.
Important things to understand here
Both the then and catch functions return new promise objects.
Either throwing or explicitly rejecting, will move the current promise to the rejected state.
Since then and catch return new promise objects, they can be chained.
If you throw or reject inside a promise handler (then or catch), it will be handled in the next rejection handler down the chaining path.
As mentioned by jfriend00, the then and catch handlers are not executed synchronously. When a handler throws, it will come to an end immediately. So, the stack will be unwound and the exception would be lost. That is why throwing an exception rejects the current promise.
In your case, you are rejecting inside do1 by throwing an Error object. Now, the current promise will be in rejected state and the control will be transferred to the next handler, which is then in our case.
Since the then handler doesn't have a rejection handler, the do2 will not be executed at all. You can confirm this by using console.log inside it. Since the current promise doesn't have a rejection handler, it will also be rejected with the rejection value from the previous promise and the control will be transferred to the next handler which is catch.
As catch is a rejection handler, when you do console.log(err.stack); inside it, you are able to see the error stack trace. Now, you are throwing an Error object from it so the promise returned by catch will also be in rejected state.
Since you have not attached any rejection handler to the catch, you are not able to observe the rejection.
You can split the chain and understand this better, like this
var promise = do1().then(do2);
var promise1 = promise.catch(function (err) {
console.log("Promise", promise);
throw err;
});
promise1.catch(function (err) {
console.log("Promise1", promise1);
});
The output you will get will be something like
Promise Promise { <rejected> [Error: do1] }
Promise1 Promise { <rejected> [Error: do1] }
Inside the catch handler 1, you are getting the value of promise object as rejected.
Same way, the promise returned by the catch handler 1, is also rejected with the same error with which the promise was rejected and we are observing it in the second catch handler.
I tried the setTimeout() method detailed above...
.catch(function(err) { setTimeout(function() { throw err; }); });
Annoyingly, I found this to be completely untestable. Because it's throwing an asynchronous error, you can't wrap it inside a try/catch statement, because the catch will have stopped listening by the time error is thrown.
I reverted to just using a listener which worked perfectly and, because it's how JavaScript is meant to be used, was highly testable.
return new Promise((resolve, reject) => {
reject("err");
}).catch(err => {
this.emit("uncaughtException", err);
/* Throw so the promise is still rejected for testing */
throw err;
});
According the spec (see 3.III.d):
d. If calling then throws an exception e,
a. If resolvePromise or rejectPromise have been called, ignore it.
b. Otherwise, reject promise with e as the reason.
That means that if you throw exception in then function, it will be caught and your promise will be rejected. catch don't make a sense here, it is just shortcut to .then(null, function() {})
I guess you want to log unhandled rejections in your code. Most promises libraries fires a unhandledRejection for it. Here is relevant gist with discussion about it.
Yes promises swallow errors, and you can only catch them with .catch, as explained more in detail in other answers. If you are in Node.js and want to reproduce the normal throw behaviour, printing stack trace to console and exit process, you can do
...
throw new Error('My error message');
})
.catch(function (err) {
console.error(err.stack);
process.exit(0);
});
I know this is a bit late, but I came across this thread, and none of the solutions were easy to implement for me, so I came up with my own:
I added a little helper function which returns a promise, like so:
function throw_promise_error (error) {
return new Promise(function (resolve, reject){
reject(error)
})
}
Then, if I have a specific place in any of my promise chain where I want to throw an error (and reject the promise), I simply return from the above function with my constructed error, like so:
}).then(function (input) {
if (input === null) {
let err = {code: 400, reason: 'input provided is null'}
return throw_promise_error(err)
} else {
return noterrorpromise...
}
}).then(...).catch(function (error) {
res.status(error.code).send(error.reason);
})
This way I am in control of throwing extra errors from inside the promise-chain. If you want to also handle 'normal' promise errors, you would expand your catch to treat the 'self-thrown' errors separately.
Hope this helps, it is my first stackoverflow answer!
Listen for unhandled errors:
window.addEventListener('unhandledrejection', e => {
// ...
});
window.addEventListener('error', e => {
// ...
});
If error gets swallowed, use self.report(error):
.catch(error => {
self.reportError(error);
});
https://developer.mozilla.org/en-US/docs/Web/API/reportError