0

I am reading a book named You dont know JS. I am at the part where the author is explaining why errors in the promise.then()'s success callback isn't designed to be caught in the error callback in the same promise.then(). In other words:

 somePromise.then(
        function success(msg){
            throw new Error()//Line A
        },
        function error(err){
            //error at Line A will not be caught here
        }
    );

Here is the actual content from the book:

var p = new Promise( function(resolve,reject){
    resolve( 42 );
} );

p.then(
    function fulfilled(msg){
        foo.bar(); //Line C: will throw error because foo is null
        console.log( msg ); // never gets here :(
    },
    function rejected(err){//Line D
        // never gets here either :(
    }
);

Why couldn't it just call the error handler we have defined there (he is talking about callback at Line D)? Seems like a logical behavior on the surface. But it would violate the fundamental principle that Promises are immutable once resolved. p was already fulfilled to the value 42, so it can't later be changed to a rejection just because there's an error in observing p's resolution.

I have problem with this line:

p was already fulfilled to the value 42, so it can't later be changed to a rejection just because there's an error in observing p's resolution.

IMO, even if the error in Line C would have been designed to be caught in Line D, it wouldn't have any impact on original promise (p). Simply because .then() will return a new promise which is in no way related to original promise. Author seems to think otherwise. IMHO, what they should have said instead:

When an error is thrown in Line C, a new, rejected Promise has been created so it can't later be given to callback at Line D, since rejected Promise is immutable Promise.

Am I missing something here?

Source of content: link

  • I did not understand your suggestion. But you are right a new rejected promise is created. And the error handler is on the successful `p` promise. – Roland Starke Sep 29 '18 at 20:35
  • Author is explaining the design choise: why rejected promise in success callback isn't handed over to error callback. I think their reasoning is wrong, since the return value of sucess callback isn't doesnt impact the original promise. My reasoning is: since the error in success callback has already created a new immmutable promise, we will achieve nothing by passing it to error callback because its immutable. – sdasdasda asdsadas Sep 29 '18 at 20:41

1 Answers1

0

This is confusing. I think the point that the author is trying to make goes like this

  1. rejected runs if and only if p is rejected
  2. if an exception in line C were to cause a call to the rejected handler, it would need to reject p to do that
  3. since p is immutable and cannot be rejected from a then handler on it, it follows that line C cannot cause that call

This is a bit like circular reasoning, because #1 would also follow from our deduction that line C doesn't cause rejected to run. We only need to accept #1 as the reasonable design choice.

But yes, your understanding of the matter is completely fine.

Bergi
  • 630,263
  • 148
  • 957
  • 1,375