[whatwg] Stack trace in window.onerror
waldron.rick at gmail.com
Fri Jul 12 15:02:29 PDT 2013
On Fri, Jul 12, 2013 at 5:51 PM, Garrett Smith <dhtmlkitchen at gmail.com>wrote:
> On 7/12/13, James Greene <james.m.greene at 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
> > a `stack` property on their core `Error` prototypes, so it seems to me
> > the only thing preventing us from getting that useful information for
> > unhandled errors is the fact that `window.onerror` does not provide us
> > 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
> 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:
window.onerror out of scope for ES.
More information about the whatwg