We Keep Coding

What are the consequences of handling a rejected promise too early?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise
Handling a rejected promise too early has consequences further down the promise chain.
What kind of consequences can be there? In which cases should early handling of rejections be avoided and in which cases should early handling of rejections be preferred?

The critical part to understand is that catch() also returns a promise.
Consider the following example. Since the intermediate catch has no return BUT catch() itself returns a promise, the final catch never fires and the final then() does ... receiving a result of undefined from the prior catch() promise
const func = (val) => {
return new Promise((resolve,reject)=> {
// not really asynchronous, only contrived for demo
val === 1 ? resolve(val) : reject('Oooops')
}).catch(err=> {console.log('Err in func catch:', err)})
}
func(200).then(res=> console.log('Then res=', res))// receives undefined from prior catch
.catch(err=> console.log('Never gets called'))
So you could do several things differently here depending on preferred logic.
You could return a different expected value from the intermediate catch and look for that in the final then, or return another rejected promise or thrown error to be caught in the final catch().
Or...don't use the middle catch at all if it serves no value intercepting it.
Example use case for using the intermediate catch would be:
A map() of request urls passed through a function that returns the request promise back to your map array but you are OK if not all succeed.
Without the intermediate catch intercepting, the whole chain would break at first bad request. Instead you can return something from intermediate catch that you filter out in a Promise.all().then()

Are `.then` and `.catch` Promise handlers somehow paired and treated like `.then(resolutionHandler, rejectionHandler)`?

When working with promises in JavaScript, we have a possibility to use .then, .catch and .finally. Each of these methods returns a new Promise object.
Using .then is pretty straightforward - we chain them. The use case for finally - is to put it at the end of the chain of .then and .catch. But
In the code below, as I understand, we initialize promise p which can resolve or reject. I could use .then(resolutionHandler, rejectionHandler), which would be self-explanatory as it's only 1 .then "handler" with both handlers, but in case of sequencing .then and .catch instead of the latter approach-
**Are .then and .catch handlers somehow paired and treated like .then(resolutionHandler, rejectionHandler)? or something else is happening? **
const p = new Promise((resolve, reject) => {
reject("ups...");
});
p
.then(data => {
// this is success handler for Promise "p"
})
.catch(err => {
// Is this failure handler for Promise "p"?
})

Not exactly. When you have p.then(handleThen).catch(handleCatch), if p rejects, handleCatch will handle it. But handleCatch will also handle errors thrown by handleThen.
Although those sorts of errors are pretty unusual with if handleThen contains only synchronous code, if handleThen returns a Promise, handleCatch will be able to handle that Promise if it rejects.
<somePromiseChain>
.catch(handleCatch);
will have the handleCatch handle any errors thrown anywhere in the above Promise chain.
In contrast, with p.then(resolutionHandler, rejectionHandler), the rejectionHandler will only handle a rejection of p. It will completely ignore anything that occurs in resolutionHandler.
If the resolutionHandler is completely synchronous, doesn't return a Promise, and never throws (which is pretty common), then .then(resolutionHandler, rejectionHandler) is indeed equivalent to.then(resolutionHandler).catch(rejectionHandler). But it's usually a good idea to use .then(..).catch(..).
With p.then(success).catch(fail), the .catch is actually attached to the Promise returned by the .then - but if p rejects, the .then's Promise rejects as well, with the same value as p's rejection. It's not that the catch is attached directly to p, but it's attached to a .then which passes p's rejection through.
Every .then / .catch is attached directly to the upper Promise it's called on, but sometimes that upper Promise passes through the value from its upper Promise unaltered. That is. p.then(undefined, fail).then(success) will run success if p resolves, with the intermediate .then passing the resolution through. With rejection, p.then(success).catch(fail) will run fail because the .then(success) passes the failure from p through unaltered.

Calling catch internally calls reject
As per mdn
The catch() method returns a Promise and deals with rejected cases only. It behaves the same as calling Promise.prototype.then(undefined, onRejected) (in fact, calling obj.catch(onRejected) internally calls obj.then(undefined, onRejected)).

Uncaught (in promise) undefined when post function fails [duplicate]

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);
});
};

Is there any way to check error in each Promise in promise.all when there is a promise error

I have one array of promises that each one execute a code that can have a javascript error and break the script. I need to check for each promise and catch any error. The problem is that the promise has timeout functions inside. Is there anyway to solve this?
Example code:
function apiRequest(url,customError) {
return new Promise(function (resolve, reject) {
if(customError) {
setTimeout(() => {
//Force error
var ar = url.asdasd.eadasd;
ar = ar.split('123')
},3000)
}
if (url) {
return resolve(url);
} else {
return reject('apiRequest failed!');
}
})
.catch(function(err){
return 'error on javascript code';
});
}
var p1 = apiRequest('urlOne',true);
var p2 = apiRequest(false,false);
var p3 = apiRequest('urlThree');
Promise.all([p1, p2, p3])
.then(function(res){
console.log('Promise.all', res);
}, error => {
console.log('Error on reject')
})
.catch(function(err){
console.error('err', err);
});
Result:
Promise.all [ 'urlOne', 'error on javascript code', 'urlThree' ]
var ar = url.asdasd.eadasd;
TypeError: Cannot read property 'eadasd' of undefined
If there is an error inside each promise, my code can catch it but if there is a timeout and the error happends after the promise finish I cant catch it and my code breaks, is there anyway to catch this error?

Is there any way to check error in each Promise in promise.all when there is a promise error?
By design, Promise.all() resolves when ALL promises you passed it have resolved or it rejects when any single promise in it rejects. It does not, by design, wait for all promises to resolve or reject and then give you all the results whether they resolved or rejected.
Functionality like that is typically named something like Promise.settle() and you can fairly easily build that type of functionality by just adding a .catch() handler to each promise you pass Promise.all() so that instead of rejecting, it resolves, but with a value that you can later tell that it actually rejected.
You can see several various implementations of .settle() type functionality in this answer:
ES6 Promise.all() error handle - Is .settle() needed?
If there is an error inside each promise, my code can catch it but if there is a timeout and the error happends after the promise finish I cant catch it and my code breaks, is there anyway to catch this error?
The way you have structured your setTimeout(), it is not connected at all to the promise that it is inside of. If you want them connected, then you have to wait to resolve until after the timeout is done and then, and only then, can you know if you should resolve or reject.
Since the code you show inside your setTimeout() looks like pseudo-code (that doesn't actually do anything yet), it's hard for us to see exactly what the point of the setTimeout() is to know exactly what you are trying to achieve and thus what a good suggestion would be.
This answer about using setTimeout() as part of a promise chain might be relevant:
using setTimeout on promise chain.
In that case, the timer is inserted into the promise chain so that things are sequenced before it and after it. As you show it now, it's a completely separate parallel path of execution that has no connection at all to your promise chain.
If all you're trying to do with the setTimeout() is to invoke a timeout if your api request does not return before the timer fires, then you can likely implement that by just calling reject() inside the setTimeout(). If the api request has already completed and already called resolve(), then calling reject() will do nothing at that point. If the api request has not yet finished, then calling reject() will reject the host promise.

Could not understand the note with Promise.prototype.then() in MDN Document

I'm learning to convert my Node.js code style from callback to promise which seems to be the tendency and it has many advantages. To prevent the misunderstanding of the important points and benefits of the promise, I'm reading
document on MDN . I can understand Examples in this page, but I am not clear with the note that at the beginning of the document, it had mentioned :
Note: ... If the first argument is omitted or provided a non-function,
the new Promise that is created simply adopts the fulfillment state of
the Promise that then is called on (if it becomes fulfilled). If the
second argument is omitted or provided a non-function, the new Promise that
is created simply adopts the rejection state of the Promise that then is called
on (if it becomes rejected).
Sorry in advance if this is trivial.
Hope for the explanation with examples, thanks.

EDIT: Updated to better match the spec - see here and here.
The .then method calls one of two functions, depending on whether or not the Promise it's attached to has fulfilled or rejected. It then returns a new Promise based on the result of that call. This allows you to run different logic depending on whether or not a Promise was successful, and makes it possible to chain Promises together easily.
If you decide not to pass in one of those functions, however, it uses sensible defaults - which is what the note you posted is alluding to. It's probably a lot easier to demonstrate than to describe, though!
If you leave out the onRejected callback, like so:
myPromise.then(function (value) {
console.log("success!");
});
The result is the same as doing this:
myPromise.then(function (value) {
console.log("success!");
}, function (reason) {
throw reason;
});
If you leave out the onFulfilled callback, like so:
myPromise.then(null, function (reason) {
console.log("fail!");
});
The result is the same as:
myPromise.then(function (value) {
return value; // the same as returning Promise.resolve(value)
}, function (reason) {
console.log("fail!");
});
If you leave both out... it's basically pointless, but still:
myPromise.then();
This is effectively the same thing as:
myPromise.then(function (value) {
return value;
}, function (reason) {
throw reason;
});
Which is in turn, basically just:
myPromise

The other answers provide good explanations, but it might be easier to express this using the concept of skipping over.
If and when the promise fulfills, then the first argument to then is invoked (as long as it is a function); if and when the promise rejects, then the second argument to then is invoked (as long as it is there and is a function). In other cases, the .then is just skipped over.
Purists would object that it is incorrect to say the .then is "skipped over", and that what is really happening is that the .then creates a new promise which is equivalent to (or assumes the state of) the original promise. That's technically correct, but informally it's easier to talk and think about the .then getting "skipped".
Examples:
function log(v) { console.log("value", v); }
function err(e) { console.log("error", e); }
Promise.resolve(1).then(null, err).then(log);
^^^^^^^^^^^^^^^ "SKIPPED" (onFulfilled is null)
Promise.reject(1).then(log).catch(err);
^^^^^^^^^ "SKIPPED" (onRejected is not given)
For completeness, the corresponding behavior for catch is:
If and when the promise rejects, then the argument to catch is invoked (as long as it is a function). In other cases, the .catch is just skipped over.
Promise.resolve(1).catch(err).then(log);
^^^^^^^^^^ "SKIPPED" (promise did not reject)
If you think about it carefully, you will see that this all means that .then(null, handler) is exactly equivalent in every way to .catch(handler). So catch can be thought of as a kind of convenience routine.
But what's the point of allowing, but then ignoring, non-function handlers? Shouldn't they throw a TypeError or something instead? Actually, this is a "feature" which can be used as follows:
promise.then(isWednesday && wednesdayHandler)
If it's Wednesday, then this will evaluate to wednesdayHandler and we can do some special Wednesday processing. It it's not Wednesday, then this will evaluate to false, which is obviously not a function, so the whole then clause will be "skipped".

I don't have too much to add to this that the other answers don't already--just that I came to this question in the process of writing my own question about this, at which point SO miraculously suggested this one as a possible duplicate (when it did not come up in my previous search attempts).
Anyways the current documentation on MDN on the parameters to Promise.prototype.then have changed a bit since the OP and I think are still confusing, if not even moreso than before, so I thought I would add a follow-up answer concerning the current documentation which reads:
onFulfilled Optional
A Function called if the Promise is fulfilled. This function has one argument, the fulfillment value. If it is not a function, it is internally replaced with an "Identity" function (it returns the received argument).
What's confusing about this wording is it's not totally clear what is the antecedent of "received argument". Without already being familiar with the details of the Promises spec, one could read this as the "identity" function returning the argument received by the then() call. I.e. that something like this:
let promise = new Promise((resolve, reject) => resolve("value"));
let chained = promise.then("new value");
is equivalent to this:
let promise = new Promise((resolve, reject) => resolve("value"));
let chained = promise.then(() => "new_value");
so that the value resolved from chained is "new_value".
When in fact, "received value" refers to the resolved value of the original promise that .then() was chained from, i.e.:
let promise = new Promise((resolve, reject) => resolve("value"));
let chained = promise.then(() => "value");
So writing promise.then("not_a_callable") completely ignores "not a callable" and is resolved to the value that fulfilled the original promise, whatever it happens to have been.
Personally, I think this confusing behavior, but it is what it is.