[whatwg] Proposal: Add window.getLastError (or modify invocation arguments of window.onerror)

[Garrett Smith]

On 2/4/13, Nathan Broadbent <nathan.f77 at gmail.com> wrote:
> Hi,
>
Hi Nathan -

> The current information passed to window.onerror rarely provides
> sufficient information to find the cause of the error. The column
That's putting it mildly.

> 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?

I'm not married to the idea of having it be stuck onto window.onerror.
There should be some way to get at the stack trace.

[whatwg] window.onerror -ancient feature needs upgrade
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-September/012552.html

| There needs to be a way to capture errors on the window.
|
| A method that passes an Error to the handler. One possible solution
| would be to leverage the existing event system:
|
| addEventListener( "error", genericErrorEventHandler, false );
|
| function genericErrorEventHandler( errorEvent ) {
| };

There's a number of bugs for global error stack info.

Bug 355430 - Stack information of uncaught Error object should be
available in window.onerror
https://bugzilla.mozilla.org/show_bug.cgi?id=355430

Bug 104408 - Summary: Add exception object and stack trace to window.onerror
https://bugs.webkit.org/show_bug.cgi?id=104408

| "The spec explicitly states that onerror gives you the
| error string, url, and line number.  We can't arbitrarily
| extends a spec as we see fit."

Bug 55092 - Stack information of uncaught Error object should be
available in window.onerror
https://bugs.webkit.org/show_bug.cgi?id=55092
"Is there anything else blocking this?"

https://bugs.webkit.org/show_bug.cgi?id=13646
(Apparently I "duplicated" that bug before the original, which came
four years later O_o (or "search first!")).


[...]

>>  but ideally I
>>> would just have access to the full "Error" object so I can always have
>>> an
>>> up-to-date model if the "Error" object continues to change (as it
>>> probably
>>> will).
>>>
I agree.

>>
>> That's fair enough. Though not all exceptions are Errors -- DOMException
>> currently isn't, though I think some people want it to somehow inherit
>> from
>> Error.
>>
Why not?

>>
>>  For example, some devs may be interested in the "Error" object's
>>> "name" property, which is already a part of the object today but is not
>>> provided to "window.onerror" callbacks.  And again, if additional
>>> properties are added in the future, it's just more and more properties
>>> that
>>> may need to get incrementally added to the "window.onerror" invocation
>>> arguments list.  For example, I proposed the addition of an "innerError"
>>> property (or some would call it "cause") for chaining errors and masking
>>> internal errors that consumers shouldn't see, instead providing a
>>> customer-facing message.
>>>
>>
>> Yeah.
>>
Yep. Pass an error object with a stack trace.



>>
>> Yes. Since the script doesn't compile, the same script can't catch any
>> exception in a try/catch block. onerror is just invoked with the
>> appropriate arguments, and currently doesn't expose any object. Hence,
>> compile errors currently do not expose any exception that Web pages can
>> observe. However, if we change onerror and expose the exception object
>> for
>> uncaught exceptions, it would certainly make sense to specify that
>> compile
>> errors be exposed using SyntaxError exceptions.
>>
Early errors?
www.ecma-international.org/ecma-262/5.1/#sec-16
-- 
Garrett
Twitter: @xkit
personx.tumblr.com