If I'm a function that returns a rejected promise, why would I care whether or not the caller handles it or not? Especially since there's really no real way to know this in an accurate way (considering that often times, a .catch() might just reject with the same error when it's not able to handle it). What would be an instance where this is useful? This feels a little upsidedown - shouldn't it be the caller's job to decide how to handle the "default catch case" (or unhandled promise)?
Or is Promise.uncaught() intended only for cases where the whole chain is present in the same function (the promise isn't being returned), in which case, it doesn't seem like it's any different from just putting a .catch() at the end.
If Promise.uncaught provides a default handler for only specified one promise, it is as same as adding Promise.prototype.catch in the end.
If it provides a globally registered fallback handler for all promises, it seems that it is as same as UnhandledRejection.
What I really need may be something like EPromise, in which I can easily define a global default handler via implementing EPromise.prototype.uncaught. Besides, there are some interesting inspired operations on EPromises like:
-
EPromise.abort: abort the remained chain of a promise
-
EPromise.rethrow: rethrow a error to the uncaught handler
-
EPromise.prototype.{onRTN,onERR}: like fulfilled / rejection handlers, but any returned value of them won't change the promise chain itself