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

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@opera.com> wrote:

> On Fri, 11 May 2012 17:14:00 +0200, James Greene <james.m.greene@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 Friday, 11 May 2012 17:54:44 UTC