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

Hi,

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?


Best,
Nathan


> Alright... so what's next?  I'm assuming this needs further discussion with
> other WHATWG members chiming in.  If I can help, please let me know. I'd
> like to see this request through.
> Sincerely,
>     James Greene

On Fri, May 11, 2012 at 12:26 PM, Simon Pieters <simonp at opera.com> wrote:
> On Fri, 11 May 2012 17:14:00 +0200, James Greene <james.m.greene at gmail.com>
> wrote:
>
>  Simon:
>> Yeah, I misunderstood your previous mention of having it as a [fifth]
>> string argument.  I somehow associated that automatically with the
>> "message" parameter (the only string argument, I suppose) but I also
>> noticed my mistake after I sent the email.
>>
>
> OK.
>
>
>  I personally am interested in adding the stack trace, yes,
>>
>
> OK, thanks.
>
>
>  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).
>>
>
> 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.
>
>
>  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.
>
>
>  You keep mentioning compile errors and how they don't have associated
>> "Error" objects but it sounds like they still reach the "window.onerror"
>> callbacks.  Can you add a little commentary on that?
>>
>
> Here are some examples:
>
> <script> onerror = function(a,b,c) { alert(a+b+c) }; </script>
> <script> foo(); </script> <!-- "runtime" error; uncaught exception -->
> <script> for (;) </script> <!-- "compile" error; no exception, but onerror
> is invoked -->
> <script> setTimeout('for (;)', 0); </script> <!-- also compile error -->
> <img src="" onerror="for(;)"> <!-- also compile error -->
>
>
>
>  I thought they
>> utilized the "SyntaxError" class but perhaps that's only for "eval()"
>> calls...?
>>
>
> 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.
>
> If we expose the exception object in onerror (which I actually think makes
> sense), what do we want to happen for cross-origin script errors? null? The
> current arguments are masked as ("Script error.", "", 0, 0).
>
>
>  I may also be thinking of this differently as a JS engineer
>> versus a browser vendor, so please help clue me in.  I'm interested to
>> learn more on this, and it may help me better appreciate why the
>> "window.onerror" callback mechanism *didn't* just pass an "Error" object
>> from the beginning.
>>
>
> I think onerror is an old feature dating back from old Netscape or IE
> (don't know which). Then other browsers just copied it.
>
>
>  I appreciate your continued feedback. Thanks!
>>
>
> cheers
>
> --
> Simon Pieters
> Opera Software
>

Received on Monday, 4 February 2013 22:10:02 UTC