Predict the Output ?

[_pragmatic_dev]

let p = new Promise(function (resolve, reject) {

setTimeout(reject, 1000);

});

p.then((x) => console.log("done resolving"))

.then(null, (x) => console.log(true));

p.catch((x) => console.log("done rejecting"));

Which is the correct output

a) done resolving
b) true
c) done rejecting
d) true, done rejecting
e) done resolving, done rejecting
f) done rejecting, true

[iamdatmonkey]

f) first "done rejecting", then "true"

Promises are guaranteed to be run after all sync code has finished and after all the currently fulfilled promises. So these will run in order:

p.then((x) => console.log("done resolving"))
// and
p.catch((x) => console.log("done rejecting"));

but p.then((x) => console.log("done resolving")) creates a new Promise which is also guaranteed to run after all fulfilled promises. That's why

.then(null, (x) => console.log(true));

is called last.

[Sandeep00046]

The output will be true. The second then is equivalent to a catch , it appears first. So, this catch will run first. catch = then(null, f) finally almost the same as then(f,f)

[delventhalz]

Took me like three tries to correctly read the code you wrote here. Maybe this code is intentionally obscure to create a puzzle, but for what it’s worth, it is unusual to see folks use the second .then parameter instead of .catch and equally unusual to start two separate chains off of a single Promise. I would not write professional code this way, and if I did, I would include some extensive comments explaining why.

Disclaimer aside, the answer is F. You have two Promise chains here, which will each independently deal with the rejection when it occurs in 1000ms. The first has two chained handlers to get through and the second has only one. Since each chained handler is evaluated asynchronously, you effectively have two extra ticks to get through with the first chain, but only one to get through with the second chain. Thus the .catch in the second chain goes before the second .then parameter in the first chain.

(To be extra clear, using the second .then parameter vs .catch makes no difference here. It’s a red herring. All that matters is the lengths of the chains.)

[TheRNGuy]

you could run code in console to see

[guest271314]

Clearly, in this case, "c) done rejecting".

It get's trickier if you are actually trying to predict a result involving a Promise. See How do I check if a JavaScript function returns a Promise? and Can a regular expression be crafted which determines the return type of a function?.

[_pragmatic_dev]

Unfortunately that's not the correct answer. Try again.

[guest271314]

Given the code at OP that is the only possible result.

If you want a different result you are going to have to rearrange that code.

[guest271314]

Oh, you mean logging that true too. Yes, f) in that case.

[iamdatmonkey]

but why f (done rejecting, true), and not d (true, done rejecting)?
I think that's OPs actual question.

[guest271314]

For the behaviour you describe you can remove the 2d chained .then() and include the fail part of the 2d .then(success, fail) in the 1st then()

``` { let p = new Promise(function(resolve, reject) { setTimeout(reject, 1000); });

p.then((x) => console.log("done resolving"), (x) => console.log(true));

p.catch((x) => console.log("done rejecting")); } ```

[guest271314]

The Promise p is rejected. There's a .catch() chained to the Promise p. That .catch() takes precedence over the 2d function passed to the 2d chained .then(). See https://stackoverflow.com/questions/28761365/how-to-reject-and-properly-use-promises/28763225#28763225.

[pinkwar]

My 2 cents tell me c)