This most recently came up in the context of creating polyfills for 
requestAnimationFrame, but pretty much any self-hosted event-dispatching 
system runs into this problem.

Consider an API like this:

   addListener: function(callback) {
     this.callbacks.push(callback);
   }

   notifyListeners() {
     // call all the callbacks here
   }

Examples in the web platform include DOM event dispatch, mutation 
records, requestAnimationFrame, promise callbacks, and pretty much 
anything else that makes use of microtasks or enters user script 
multiple times off a single task.  I would be somewhat surprised if 
other ES embeddings did not have similar constructs.

There are fundamentally two different implementation strategies for 
notifyListeners.  The first looks like this:

   for (listener of listeners) {
     listener();
   }

and the second looks like this:

   for (listener of listeners) {
     try {
       listener();
     } catch (e) {
       // Now what?
     }
   }

The first strategy has the problem that a listener throwing an exception 
prevents later listeners from being notified, which is suboptimal.  The 
second strategy has the problem that there is no way to route the caught 
exceptions through the embeddings normal exception-reporting mechanisms 
(window.onerror, console, etc).  In particular, there is no way to 
explain in terms of the APIs available to the script the actual behavior 
of browser embeddings in situations like this.

So what I'd like to propose is some API that takes a value and routes it 
through the codepath uncaught exceptions get sent through.  If such an 
API existed, one could implement notifyListeners as:

   for (listener of listeners) {
     try {
       listener();
     } catch (e) {
       ourNewAPI(e);
     }
   }

We can obviously add such an API in the web platform if we need to, but 
I wanted to check whether there's interest in having such an API on the 
language level in ES, given that other ES embeddings should have similar 
problems here.

Thoughts?

Note that so far I'm just asking whether this should be part of ES 
proper or not; we can decide on the exact naming and where to hang the 
API once we decide whether it's part of the language or specific to 
browser embeddings.

-Boris

This most recently came up in the context of creating polyfills for 
requestAnimationFrame, but pretty much any self-hosted event-dispatching 
system runs into this problem.

Consider an API like this:
```js
addListener: function(callback) {
  this.callbacks.push(callback);
}

notifyListeners() {
  // call all the callbacks here
}
```

Examples in the web platform include DOM event dispatch, mutation 
records, requestAnimationFrame, promise callbacks, and pretty much 
anything else that makes use of microtasks or enters user script 
multiple times off a single task.  I would be somewhat surprised if 
other ES embeddings did not have similar constructs.

There are fundamentally two different implementation strategies for 
notifyListeners.  The first looks like this:

```js
for (listener of listeners) {
  listener();
}
```
and the second looks like this:

```js
for (listener of listeners) {
  try {
    listener();
  } catch (e) {
    // Now what?
  }
}
```

The first strategy has the problem that a listener throwing an exception 
prevents later listeners from being notified, which is suboptimal.  The 
second strategy has the problem that there is no way to route the caught 
exceptions through the embeddings normal exception-reporting mechanisms 
(window.onerror, console, etc).  In particular, there is no way to 
explain in terms of the APIs available to the script the actual behavior 
of browser embeddings in situations like this.

So what I'd like to propose is some API that takes a value and routes it 
through the codepath uncaught exceptions get sent through.  If such an 
API existed, one could implement notifyListeners as:

```js
for (listener of listeners) {
  try {
    listener();
  } catch (e) {
    ourNewAPI(e);
  }
}
```

We can obviously add such an API in the web platform if we need to, but 
I wanted to check whether there's interest in having such an API on the 
language level in ES, given that other ES embeddings should have similar 
problems here.

Thoughts?

Note that so far I'm just asking whether this should be part of ES 
proper or not; we can decide on the exact naming and where to hang the 
API once we decide whether it's part of the language or specific to 
browser embeddings.