为什么我的ES6 Promise Rejection需要立即使用以避免出现控制台错误消息？

Question

Please note: The following is an issue that behaves differently on different browsers. So perhaps this is a browser implementation issue. I would love some advice regardless.

In my application, I am creating a couple of promises that I may not be consuming until quite some time in the future. Which should be fine, they are promises, after all.

If the promise being stored away is resolved, there is no issue. I can consume it as far in the future as I want, and as many times as I want. As expected.

If the promise being stored away is rejected, however, there is an issue. Unless I consume that rejection shortly after it is made (not sure how shortly) a console message will crop up in Chrome or Firefox indicating that there is an uncaught promise rejection/error. IE does not pop up that error.

So consider the following code:

console.log("About to make a promise rejection.");
var foo = Promise.reject(new Error("Foo Rejected Promise."));
console.log("Promise rejection made.");

Note that there is no use or consumption of the promise foo. It is merely stored away for some future use.

The console on IE looks like this:

About to make a promise rejection.

Promise rejection made.

Which is expected. However, the same code on Chrome will yield the following console:

About to make a promise rejection.

Promise rejection made.

Uncaught (in promise) Error: Foo Rejected Promise.(…)

Firefox looks pretty much like Chrome, other than the wording around the "uncaught" error.

But the thing is that I intend to handle this "error" much later, at the time I am consuming the promise. Merely HAVING a rejected promise should not cause a console error..... that should happen if I consume the promise and don't handle the error.

To simulate a "much later" handling of the error, consider this alteration of the code:

console.log("About to make a promise rejection.");
var foo = Promise.reject(new Error("Foo Rejected Promise."));
console.log("Promise rejection made.");
setTimeout(() => {
    foo.catch((err) => {
        console.log("Displaying " + err.message + " 10 seconds later.");
    });
}, 10000);

Now in this case, we "handle" the error by displaying something on the console after a timeout. Now IE still handles this as I would expect:

About to make a promise rejection.

Promise rejection made.

Displaying Foo Rejected Promise. 10 seconds later.

In this case, Firefox does like IE, and displays exactly these messages, and does not give me an erroneous console error.

Chrome, however, still gives the erroneous error:

About to make a promise rejection.

Promise rejection made.

Uncaught (in promise) Error: Foo Rejected Promise.(…)

Displaying Foo Rejected Promise. 10 seconds later.

So Chrome both complained about my error not being handled, and then displayed that it was handled.

It appears that I can get around all this with the following code that that seems like a hack. Basically I do a "fake" handling of the error when the promise is created and then really handle it the way I want to later:

console.log("About to make a promise rejection.");
var foo = Promise.reject(new Error("Foo Rejected Promise."));
foo.catch(() => { });  // Added this hack-ish code.
console.log("Promise rejection made.");
    setTimeout(() => {
    foo.catch((err) => {
        console.log("Displaying " + err.message + " 10 seconds later.");
    });
}, 10000);

But this is ugly code.

My question is twofold - is there some way of looking at what Chrome (and to some extent FireFox) is doing and think of it as a favor? Because to me it seems awful. And secondly, is there a better way of getting around this than the hack of pretending to handle an error when you aren't?

Thanks in advance.

Answer 1

As someone who has worked with promises for a couple of years now, I understand why this behavior is set in Chrome. it is easy to forget to catch a rejected promise, and if there is an error in .then(), there will be no notification and your program will just stay silent blankly. It can be very hard to debug.

function throwException(c){ return a.b = 2 ;} //a is not defined. throws exception.
let p = q.resolve("a")
         .then(x => x + "b")
         .then(y => throwException(y))
         .then(z=> z+"c");   //this will say nothing in Q library 

this can easily create a very obscure behaviour when one forgets to catch the error.

In Q library, you have the .done() function to actually enforce what Chrome is doing here:

let p = q.resolve("a")
         .then(x => x + "b")
         .then(y => throwException(y))
         .then(z=> z+"c")
         .done();   //this will throw an exception.

So, it is a known problem in promises. Chrome have simply decided to make .done() the default behavior, asking you to explicitly .catch(_=>{}) if you want to ignore failed promises. Q has decided to make silent failure default, asking you to explicitly use .done() if you want an exception on failed promise. If you like the latter approach, you can always include a promise library. It is a matter of taste IMHO.

Answer 2

Any promise that has a chance to be rejected, should be handled, similarly to exceptions.

There are not so many chances that a promise won't be chained synchronously. But if it won't, it requires 'hack-ish' .catch(() => { }) to synchronously handle the rejection.

Chrome promise rejection behaviour puts this

var foo = Promise.reject(new Error("Foo Rejected Promise."));
foo.catch(() => { });  // Added this hack-ish code.

setTimeout(() => {
    foo.catch((err) => {
        console.log("Displaying " + err.message + " 10 seconds later.");
    });
}, 10000);

into the same error-handling boat as

try {
  throw new Error("Foo"));

  setTimeout(() => {
    try {
      throw new Error("Foo"));
    } catch (err) {
      console.log("Displaying " + err.message + " 10 seconds later.");
    }
  }, 10000);
} catch (err) {}

Wouldn't the exception wait 10 seconds to be caught by next try...catch before being thrown? It won't wait even a single tick. It requires 'hack-ish' try { ... } catch (err) {} block to perform as intended.

This behaviour is already well-known to Bluebird library users for quite a long time. Bluebird has adjustable error handling and allows to debug promises efficiently even on the large scale.

The behaviour is also known in Angular 2 development, it is forced for promises with Zone.js library.

Since promise debugging has limited value and applicable to development environment, it is possible to modify or disable this behaviour for native promises in production builds:

if (typeof DEBUG_PROMISE === 'undefined') {
  window.addEventListener('unhandledrejection', (e) => {
    e.preventDefault();
    console.warn(e.reason);
  });
}

Here's more reading on the subject.