Intent to Implement: Promise Rejection Tracking Events

[Domenic Denicola]

Contact emails

joc...@chromium.org (implementation), d...@domenic.me (spec)

Spec: https://github.com/domenic/unhandled-rejections-browser-spec

This spec is mostly complete, but will require tweaking to the timing, which we hope to nail down through implementation experience. It also doesn’t yet specify how Worker objects should dispatch these events (like they currently do for error events).

Summary

We’d like to introduce a pair of events on the global object and on Worker instances, unhandledrejection and rejectionhandled, for tracking promise rejections.

Motivation

A common desire on the web is to log any uncaught exceptions back to the server. The typical method for doing this is

   window.onerror = (message, url, line, column, error) => {
     // log `error` back to the server
   };

When programming asynchronously with promises, asynchronous exceptions are encapsulated as rejected promises. They can be caught and handled withpromise.catch(err => ...), and propagate up through an "asynchronous call stack" (i.e. a promise chain) in a similar manner to synchronous errors.

However, for promises, there is no notion of the "top-level" of the promise chain at which the rejection is known to be unhandled. Promises are inherently temporal, and at any time code that has access to a given promise could handle the rejection it encapsulates. Thus, unlike with synchronous code, there is not an ever-growing list of unhandled exceptions: instead, there is a growing and shrinking list of currently-unhandled rejections.

Our developer tools already expose this live list of currently-unhandled rejections, by interleaving them with synchronous exceptions and then graying them out and putting a checkmark next to them when/if they become handled. However, developer tools are not sufficient to satisfy the telemetry use case, i.e. the use case which is currently handled via window.onerror for synchronous code.

Compatibility Risk

This feature was discussed on the WHATWG list last September, with helpful engagement from Mozilla. I asked again recently to see if there was any support and got a more explicit statement of support from them, alongside some feedback that has shaped the API direction.

There have been no signs from other vendors. (Indeed, other vendors do not yet have devtools-based promise rejection tracking.)

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug?

https://code.google.com/p/chromium/issues/detail?id=495801

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/4805872211460096

Requesting approval to ship?

No.

[PhistucK]

I would rather not have two more properties on the global object (window.onunhandledrejection and window.onrejectionhandled). This encourages bad practices and unintended overrides, that lead to bugs that are hard to find. addEventListener is enough.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Domenic Denicola]

From: PhistucK [mailto:phis...@gmail.com]

> I would rather not have two more properties on the global object (window.onunhandledrejection and window.onrejectionhandled). This encourages bad practices and unintended overrides, that lead to bugs that are hard to find. addEventListener is enough.

Is there any precedent for omitting the corresponding onxyz for an event? Preferably a precedent involving the global object, instead of one involving other interfaces.

[Domenic Denicola]

I forgot to add that the onxyz's are how events are usually feature-detected (with `'onunhandledrejection' in window` and similar code).

> -----Original Message-----
> From: Domenic Denicola
> Sent: Monday, June 8, 2015 13:00
> To: 'PhistucK'
> Cc: blink-dev
> Subject: RE: [blink-dev] Intent to Implement: Promise Rejection Tracking
> Events

>
> From: PhistucK [mailto:phis...@gmail.com]
>
> > I would rather not have two more properties on the global object
> (window.onunhandledrejection and window.onrejectionhandled). This
> encourages bad practices and unintended overrides, that lead to bugs that
> are hard to find. addEventListener is enough.
>

[PhistucK]

DOMContentLoaded does not have an onfoo equivalent, as far as I know.

I am not sure regarding the feature detection story. I used to feature detect transition events using window.TransitionEvent. This does not feature detect a specific event, but a class of events, though.

☆PhistucK

[Philip Jägenstedt]

This sounds very useful, Domenic. As for event handler attributes, my default position is that if an event foo is fired on Window/Document/Element/etc per spec then that same interface object should have the onfoo attribute, omitting it would need some kind of justification. As you say, it's great for feature detection.

[Anne van Kesteren]

On Mon, Jun 8, 2015 at 7:09 PM, PhistucK <phis...@gmail.com> wrote:

> DOMContentLoaded does not have an onfoo equivalent, as far as I know.

If anything we should consider exposing that too. Perhaps at some
point we can have a better events API, but until that time we should
just follow precedent for new things.


--
https://annevankesteren.nl/