From: Boris Zbarsky [mailto:bzbar...@mit.edu]
On 6/24/14, 9:51 AM, Domenic Denicola wrote:
I'd be interested in collaborating on designing such a language extension.
I think I would too; I'm just not sure about availability.
For posterity, [I tried to replicate this functionality using
On 6/24/14, 9:51 AM, Domenic Denicola wrote:
I'd be interested in collaborating on designing such a language extension.
I think I would too; I'm just not sure about availability.
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
On 6/23/14, 2:54 PM, Boris Zbarsky wrote:
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.
I'd like to refocus on
I am ambivalent about where it goes; it depends to some degree with
how the feature is implemented.
`setTimeout(function() { throw e; }, 0);` is ugly, but it seems to
have most of the behavior you want. There are similar mechanisms with
promises and jobs that could be used. I believe Allan said
So to be clear: is this something that people feel should be part of
ES-the-language?
I definitely think it should be part of ES-the-language. I agree with Scott
that to some extent it depends on the shape the feature takes, but IMO this is
a fundamental capability of modern language
On Tue, Jun 24, 2014 at 8:38 AM, C. Scott Ananian ecmascr...@cscott.net wrote:
I am ambivalent about where it goes; it depends to some degree with
how the feature is implemented.
`setTimeout(function() { throw e; }, 0);` is ugly, but it seems to
have most of the behavior you want.
What.
Note first that I was trying to summarize the broad dimensions of the
alternatives discussed, not outline spec-quality proposals.
On Tue, Jun 24, 2014 at 2:43 PM, Jason Orendorff jason.orendo...@gmail.com
wrote:
On Tue, Jun 24, 2014 at 8:38 AM, C. Scott Ananian ecmascr...@cscott.net
wrote:
I
[...]
Finally, it hasn't been discussed much, but some platforms provide
explicit access to the 'uncaughtException' handler.
+1. This feature would be a complement to what bz proposed. Either
feature could be added and used independently from the other.
I’m not completely sure, but
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);
}
On Mon, Jun 23, 2014 at 8:54 PM, Boris Zbarsky bzbar...@mit.edu wrote:
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.
I just filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=26182 on
HTML since it actually
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
On Mon, Jun 23, 2014 at 11:54 AM, Boris Zbarsky bzbar...@mit.edu wrote:
for (listener of listeners) {
try {
listener();
} catch (e) {
// Now what?
}
}
Can't you just pass e into a setTimeout()'d callback, and rethrow it
from there? Does that mess with the stack
On Mon, Jun 23, 2014 at 12:08 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Mon, Jun 23, 2014 at 11:54 AM, Boris Zbarsky bzbar...@mit.edu wrote:
for (listener of listeners) {
try {
listener();
} catch (e) {
// Now what?
}
}
Can't you just pass e
On 6/23/14, 3:08 PM, Tab Atkins Jr. wrote:
Can't you just pass e into a setTimeout()'d callback, and rethrow it
from there? Does that mess with the stack or something?
It might for some thrown values in some implementations. It would
definitely mess with reported exception ordering wrt
On 6/23/14, 3:35 PM, Kevin Reid wrote:
Yes, but setTimeout may be less prompt than you want depending on the
application
Note that at least in some browsers window.onerror is called off an
event loop task anyway.
However, I'd like to propose a different facility: Instead of catch and
then
On Mon, Jun 23, 2014 at 12:44 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/23/14, 3:35 PM, Kevin Reid wrote:
Yes, but setTimeout may be less prompt than you want depending on the
application
Note that at least in some browsers window.onerror is called off an event
loop task anyway.
On 6/23/14, 4:17 PM, Kevin Reid wrote:
Clarification: I meant how promptly the listener is invoked (independent
of the error case).
Oh, yes. Calling the callback itself off a timeout is a non-starter. I
assume that Tab was talking about rethrowing the exception off a timeout.
and in
On 6/23/14, 4:25 PM, Boris Zbarsky wrote:
That's an interesting issue too. Right now I believe browsers can
internally rethrow an exception without changing its stack trace... But
there is no way for script to do that.
Actually, I might be wrong there if the stack trace is captured at the
On Mon, Jun 23, 2014 at 1:25 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/23/14, 4:17 PM, Kevin Reid wrote:
Clarification: I meant how promptly the listener is invoked (independent
of the error case).
Oh, yes. Calling the callback itself off a timeout is a non-starter. I
assume that Tab
I personally don't think it's DOM responsibility to clean up after your
errors and I'd expect DOM to keep firing if a listener set by some other
library or scope I don't know/own fails, as it has always been.
The only improvement I could think of is some info reachable through the
event object,
just to clarify first sentence:
On Mon, Jun 23, 2014 at 1:35 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I personally don't think it's DOM responsibility to clean up after your
errors and I'd expect DOM to keep firing if a listener set by some other
library or scope I don't
On 6/23/14, 4:35 PM, Andrea Giammarchi wrote:
I personally don't think it's DOM responsibility to clean up after
your errors
If I follow you correctly, what you're saying is that if there's some
buggy ad on the web page that uses requestAnimationFrame and throws in
the callback, then all
I am saying that if your requestAnimationFrame throws mine should keep
working without problems as if your click handler fails mine should still
work properly even if added after yours.
If the problem is being able to reproduce this in JS then there should be
no ticket fired in HTML land and W3C
On 6/23/14, 4:47 PM, Andrea Giammarchi wrote:
I am saying that if your requestAnimationFrame throws mine should keep
working without problems
OK. That's the current behavior, and no one is proposing changing that.
The discussion is about allowing that while usefully reporting the
thrown
On Mon, Jun 23, 2014 at 1:47 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I am saying that if your requestAnimationFrame throws mine should keep
working without problems as if your click handler fails mine should still
work properly even if added after yours.
Yes, that's the
As I've said, I haven't seen anyone mentioning the handleEvent approach
that's able to give you any info and error and stack you want whenever you
want it inside any of its listeners
```javascript
// recycle one handler
// to handle errors too
var handler = {
handleEvent: function (e) {
Yes Tab, I've seen first Anne's reply and felt the urge to jump into this
worried somebody would have changed that.
OK, let's keep it here then ... trollfaceand use an offline DOM node to
simulate the DOM behavior /trollface
Jokes a part, I've read here and there that Rick W. is going to propose
It seems to me that the best way to do this in ES6 would be to run the call
backs as individual Jobs (what until recently we were calling ES Tasks,
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-tasks-and-task-queues
). The mechanisms are already in the ES6 spec. so that any any
It seems to me that the best way to do this in ES6 would be to run the call
backs as individual Jobs
I definitely think there should be an API for queuing jobs. (At least, as long
as jobs manifest as microtasks in Node.js and the browser; otherwise they are
not as useful.)
However, I
On Jun 23, 2014, at 2:23 PM, Domenic Denicola wrote:
It seems to me that the best way to do this in ES6 would be to run the call
backs as individual Jobs
I definitely think there should be an API for queuing jobs. (At least, as
long as jobs manifest as microtasks in Node.js and the
Within a list of callbacks the DOM behavior is that the error is not
actually enqueued rather spliced in between.
with [a, b, c] and b throwing you'll have [a, b, bthrowed, c] plus this
won't easily solve the problem: where does that error actually get
triggered ?
the DOM use global `error`
From: Allen Wirfs-Brock al...@wirfs-brock.com
I was under the impression that DOM triggered event listeners ran in their
own turn
[Nope](http://jsbin.com/gaxapora/1/edit?html,console).
and that this was the model we would want to generally apply to ES events.
Maybe (probably?); there are
32 matches
Mail list logo
