This is definitely something that I've needed before. The logical place for
this is as part of the console API which is I believe has no spec (defacto
standard).
On Mon, Jun 23, 2014 at 2:54 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> 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
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
erik
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
