then(onFulfilled, undefined) - then(undefined, onRejected) - Why does catch() fulfill the returned promise?

Question

I'm trying this code:

let with999 = Promise.resolve(999);

let returnCatch = with999
.catch(reason => {
  console.log("catch: " + reason);
});

returnCatch.then(data => {
  console.log("then: " + data);
});

When I suddenly realized:

Promisewith999fulfilled Therefore catch() method is not executed < /strong>, however, The Promise returned by catch() (in this case, returnCatch) is ultimately fulfilled, with the same value as >with999.

So, my question is, why does catch() end up fulfilling the returnCatch promise?

I expected returnCatch would hang (because catch() was not executed) and using then()< /code> would do nothing occur.

The same happens with "doing the opposite", then() Rejecting a promise:

let rejected = Promise.reject(new Error('Ups!'));

let returnThen = rejected
.then(reason => {
  console.log("then: " + reason);
});

returnThen.
catch(data => {
  console.log("catch: " + data);
});

Can someone explain to me what's going on?

Answer 1

The code is the same as chaining .then and .catch to the initial Promise. This is not the case, creating a new variable for the catch requires rejecting it and then piping it to the next then.

Think of it as writing the same statement at once without using multiple variables, such behavior makes more sense. Since the Promise resolves, the first .then will be executed, and if the Promise is rejected, the first .catch will be executed, regardless of the order or declaration of them or how many variables you use to do this.

edit: This code snippet is the same as the one above, passing the same Promise.

let with999 = Promise.resolve(999).catch(reason => {
  console.log("catch: " + reason);
}).then(data => {
  console.log("then: " + data);
});

Answer 2

The "why" question is always hard to answer, but it basically boils down to this: because it works.

Perhaps this is not obvious from the behavior of catch() passing the fulfillment result, but take a look at the second example of .then() passing about Rejection: We want to execute a .catch() callback to handle any errors that occur early in the promise chain. We don't want the Promise chain to stop in the middle (the Promise remains pending) because an error occurs and the .then() callback is not executed.

You have realized that this behavior is symmetric between .then(handleResult) and .catch(handleError). But note that these are really just simplified syntaxes for .then(handleResult, null) and .then(null, handleError). then Method actually takes two parameters, one to handle fulfillment and one to handle rejection. You can (and usually should) pass both exams at the same time.

.then() The returned Promise is resolved based on the result of the corresponding handler (rejected if the call throws an exception), the idea behind Promise chaining is that it is always initially The commitment was resolved only after the commitment was resolved. If no corresponding callback is provided, by default only the result is passed - whether .then(null, null), .then(null, handleError) has fulfilled the Promise or been .then(handleResult, null) on a rejected Promise.