core-js: Remove unhandled promise rejection code.

https://github.com/zloirock/core-js/blob/master/modules/es6.promise.js#L100-L106

The Promise spec doesn’t have this for a good reason, please remove it or at least make it easy to globally disable. There is discussion about what to do about this situation https://github.com/promises-aplus/unhandled-rejections-spec/issues but it isn’t getting much traction because without a finalizer you can’t be sure when someone is done with a promise.

Most of the proposed solutions assume that you are using promises in a very particular way and while it is not terribly uncommon, the promise spec was intentionally written to make promises more generalized than that.

The use cases where this “feature” falls apart is when you have fulfilled promises that are saved and used later. A simple example is this:

let foo = Promise.reject(new Error("failure"));
setTimeout(() => foo.then(_ => console.log("success"), _ => console.log("failure")), 1);

In this example, foo will be seen as having failed without any rejection handler and an error will be logged. However, you can see that the promise was checked for success/failure at a later time (possibly much later). If you use promises in this way right now you are hammered with failure messages even though your code is working perfectly fine.

The unhandled promise rejection logic, as currently implemented, discourages people from writing code that treats promises as a first-class citizens and instead delegates them to callback aggregators/transformers. A promise is an object that may have a useful lifetime that far exceeds the the executor. They are intended to store the result of the executor (success or failure) until they are garbage collected.

A more concrete example would be pre-fetching some web resources that you expect you’ll need later. A rejection is a reasonable (and intended) state for a promise to be in and you may not attach a then to the promise until much later in your application when you need the data. At that point it would be appropriate to check for an error, you just happened to have prefetched the data to improve the responsiveness of your application.