Re: [whatwg] Stack trace in window.onerror
Ian —
So Paul Irish pointed out to me that the spec has just been updated to
include this:
http://html5.org/tools/web-apps-tracker?from=8085to=8086
Yay, that's awesome! :)
*Two things:*
*
*
*#1.*
My last name ends with an 'e' ('Greene' vs. 'Green'). Please correct that
when you get a chance. Thanks!
*#2.*
You had mentioned earlier that there is already a window 'error' event that
can be listened to via `window.addEventListener('error', fn, false);` if
you don't use `window.onerror = fn;`:
There's already an event. You can get it if you use addEventListener()
for 'error'
rather than using onerror.
(It's also exposed on the event object, for those of you using
addEventListener()
for error events rather than onerror.)
Is that clarified in the spec somewhere already? Although that makes
perfect sense to me, I have never noticed it before nor heard of any
browser vendors implementing such. Have there been any such
implementations yet? If so, that's *wonderful* news. :)
Sincerely,
James Greene
On Wed, Jul 24, 2013 at 4:27 PM, James Greene james.m.gre...@gmail.comwrote:
Rick —
Thanks for clarifying/correcting both my comment and Hixie's!
Sincerely,
James Greene
On Wed, Jul 24, 2013 at 4:24 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Wed, Jul 24, 2013 at 2:50 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 12 Jul 2013, James Greene wrote:
On Fri, Jul 12, 2013 at 12:17 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 5 Feb 2013, Nathan Broadbent wrote:
The current information passed to window.onerror rarely provides
sufficient information to find the cause of the error. The column
number argument will be a big step forward, but a stack trace
would
be especially useful. I would like to add my support for improving
the window.onerror arguments, with a fifth argument for stack
trace.
Is there anything that James or I could do to move this discussion
along?
This seems useful, but I don't think it's specific to
window.onerror.
I would recommend approaching the es-discuss list about this.
I'm curious: would do you say that? All evergreen browsers already
include a `stack` property on their core `Error` prototypes, so it
seems
to me that the only thing preventing us from getting that useful
information for unhandled errors is the fact that `window.onerror`
does
not provide us with a real Error object instances (or even fake ones
with shell properties in the case of cross-domain errors).
Ah, I was unaware of Error.stack. Interesting!
There is no static property with the name stack on the [[Global]]
built-in Error object, nor is the property added to Error.prototype. In
v8,
SpiderMonkey and JSC, the stack property appears on the actual instance
object initialized by Error.
Rick
Re: [whatwg] Stack trace in window.onerror
On Fri, 26 Jul 2013, James Greene wrote:
My last name ends with an 'e' ('Greene' vs. 'Green'). Please correct
that when you get a chance. Thanks!
Oops, my apologies. Fixed.
You had mentioned earlier that there is already a window 'error' event
that can be listened to via `window.addEventListener('error', fn,
false);` if you don't use `window.onerror = fn;`:
Or indeed if you do. They both fire.
Is that clarified in the spec somewhere already?
Yeah, this was a recent change.
Although that makes perfect sense to me, I have never noticed it before
nor heard of any browser vendors implementing such. Have there been any
such implementations yet? If so, that's *wonderful* news. :)
Some quick testing shows this working in at least Firefox and Chrome. That
is, the 'error' event fires. In Chrome it has attributes message,
lineno, and filename, but it doesn't seem to in Firefox.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Stack trace in window.onerror
On Fri, 12 Jul 2013, James Greene wrote: On Fri, Jul 12, 2013 at 12:17 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 5 Feb 2013, Nathan Broadbent wrote: The current information passed to window.onerror rarely provides sufficient information to find the cause of the error. The column number argument will be a big step forward, but a stack trace would be especially useful. I would like to add my support for improving the window.onerror arguments, with a fifth argument for stack trace. Is there anything that James or I could do to move this discussion along? This seems useful, but I don't think it's specific to window.onerror. I would recommend approaching the es-discuss list about this. I'm curious: would do you say that? All evergreen browsers already include a `stack` property on their core `Error` prototypes, so it seems to me that the only thing preventing us from getting that useful information for unhandled errors is the fact that `window.onerror` does not provide us with a real Error object instances (or even fake ones with shell properties in the case of cross-domain errors). Ah, I was unaware of Error.stack. Interesting! I've added a fifth argument to onerror, which has the exception object. On Fri, 12 Jul 2013, James Greene wrote: I'd rather get an Error-like duck-typed object with this shell info for cross-domain requests than to not get a real Error object when the unhandled error *is* from the same origin. For the cross-origin case, I've set error to null. Adding the trace as another new argument to `window.onerror` is certainly an option but the parameter list is getting long and I suspect that Error prototypes may still gain additional properties in the future. Yeah, exposing the error itself seemed better. On Fri, 12 Jul 2013, Elliott Sprehn wrote: Can we just add a new event that takes an event object instead of a huge list of arguments? :) There's already an event. You can get it if you use addEventListener() for 'error' rather than using onerror. (It's also exposed on the event object, for those of you using addEventListener() for error events rather than onerror.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Stack trace in window.onerror
On Wed, Jul 24, 2013 at 2:50 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 12 Jul 2013, James Greene wrote: On Fri, Jul 12, 2013 at 12:17 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 5 Feb 2013, Nathan Broadbent wrote: The current information passed to window.onerror rarely provides sufficient information to find the cause of the error. The column number argument will be a big step forward, but a stack trace would be especially useful. I would like to add my support for improving the window.onerror arguments, with a fifth argument for stack trace. Is there anything that James or I could do to move this discussion along? This seems useful, but I don't think it's specific to window.onerror. I would recommend approaching the es-discuss list about this. I'm curious: would do you say that? All evergreen browsers already include a `stack` property on their core `Error` prototypes, so it seems to me that the only thing preventing us from getting that useful information for unhandled errors is the fact that `window.onerror` does not provide us with a real Error object instances (or even fake ones with shell properties in the case of cross-domain errors). Ah, I was unaware of Error.stack. Interesting! There is no static property with the name stack on the [[Global]] built-in Error object, nor is the property added to Error.prototype. In v8, SpiderMonkey and JSC, the stack property appears on the actual instance object initialized by Error. Rick
Re: [whatwg] Stack trace in window.onerror
Rick — Thanks for clarifying/correcting both my comment and Hixie's! Sincerely, James Greene On Wed, Jul 24, 2013 at 4:24 PM, Rick Waldron waldron.r...@gmail.comwrote: On Wed, Jul 24, 2013 at 2:50 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 12 Jul 2013, James Greene wrote: On Fri, Jul 12, 2013 at 12:17 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 5 Feb 2013, Nathan Broadbent wrote: The current information passed to window.onerror rarely provides sufficient information to find the cause of the error. The column number argument will be a big step forward, but a stack trace would be especially useful. I would like to add my support for improving the window.onerror arguments, with a fifth argument for stack trace. Is there anything that James or I could do to move this discussion along? This seems useful, but I don't think it's specific to window.onerror. I would recommend approaching the es-discuss list about this. I'm curious: would do you say that? All evergreen browsers already include a `stack` property on their core `Error` prototypes, so it seems to me that the only thing preventing us from getting that useful information for unhandled errors is the fact that `window.onerror` does not provide us with a real Error object instances (or even fake ones with shell properties in the case of cross-domain errors). Ah, I was unaware of Error.stack. Interesting! There is no static property with the name stack on the [[Global]] built-in Error object, nor is the property added to Error.prototype. In v8, SpiderMonkey and JSC, the stack property appears on the actual instance object initialized by Error. Rick
Re: [whatwg] Stack trace in window.onerror
Ian — I'm curious: would do you say that? All evergreen browsers already include a `stack` property on their core `Error` prototypes, so it seems to me that the only thing preventing us from getting that useful information for unhandled errors is the fact that `window.onerror` does not provide us with a real Error object instances (or even fake ones with shell properties in the case of cross-domain errors). If I'm mistaken, please clarify. Thanks! Sincerely, James Greene On Fri, Jul 12, 2013 at 12:17 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 5 Feb 2013, Nathan Broadbent wrote: The current information passed to window.onerror rarely provides sufficient information to find the cause of the error. The column number argument will be a big step forward, but a stack trace would be especially useful. I would like to add my support for improving the window.onerror arguments, with a fifth argument for stack trace. Is there anything that James or I could do to move this discussion along? This seems useful, but I don't think it's specific to window.onerror. I would recommend approaching the es-discuss list about this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Stack trace in window.onerror
On 7/12/13, James Greene james.m.gre...@gmail.com wrote: Ian — Hi James - I've interleaved, combined with your top post below. I'm curious: would do you say that? All evergreen browsers already include a `stack` property on their core `Error` prototypes, so it seems to me that the only thing preventing us from getting that useful information for unhandled errors is the fact that `window.onerror` does not provide us with a real Error object instances (or even fake ones with shell properties in the case of cross-domain errors). If I'm mistaken, please clarify. Thanks! That's my understanding. This issue has come up a number of times, for at least 10 years, so I'm surprised at Ian's answer as well. Thread: Add window.getLastError (or modify invocation arguments of window.onerror) whatwg.org/2013-February/038848.html Problem regarding getting the Error from window.onerror. The current information passed to window.onerror rarely provides sufficient information to find the cause of the error. The column number argument will be a big step forward, but a stack trace would be especially useful. I would like to add my support for improving the window.onerror arguments, with a fifth argument for stack trace. Is there anything that James or I could do to move this discussion along? Ian's reply: This seems useful, but I don't think it's specific to window.onerror. I would recommend approaching the es-discuss list about this. Is there a proposal on es-discuss that addresses this global error stack situation? Thanks, -- Garrett Twitter: @xkit personx.tumblr.com
Re: [whatwg] Stack trace in window.onerror
On Fri, Jul 12, 2013 at 5:51 PM, Garrett Smith dhtmlkitc...@gmail.comwrote: On 7/12/13, James Greene james.m.gre...@gmail.com wrote: Ian — Hi James - I've interleaved, combined with your top post below. I'm curious: would do you say that? All evergreen browsers already include a `stack` property on their core `Error` prototypes, so it seems to me that the only thing preventing us from getting that useful information for unhandled errors is the fact that `window.onerror` does not provide us with a real Error object instances (or even fake ones with shell properties in the case of cross-domain errors). If I'm mistaken, please clarify. Thanks! That's my understanding. This issue has come up a number of times, for at least 10 years, so I'm surprised at Ian's answer as well. Thread: Add window.getLastError (or modify invocation arguments of window.onerror) whatwg.org/2013-February/038848.html Problem regarding getting the Error from window.onerror. The current information passed to window.onerror rarely provides sufficient information to find the cause of the error. The column number argument will be a big step forward, but a stack trace would be especially useful. I would like to add my support for improving the window.onerror arguments, with a fifth argument for stack trace. Is there anything that James or I could do to move this discussion along? Ian's reply: This seems useful, but I don't think it's specific to window.onerror. I would recommend approaching the es-discuss list about this. Is there a proposal on es-discuss that addresses this global error stack situation? To clarify, the only involvement TC39/es-discuss has with the specification of Error stack traces is here: http://wiki.ecmascript.org/doku.php?id=strawman:error_stack . window.onerror out of scope for ES. Rick
