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

Simon emailed me personally to answer my last question about what's next: "We
wait for the editor to process this thread. It might take a while, but
he'll get to it."

Other than that, there haven't been any discussions that I've been privy to.

Sincerely,
    James Greene




On Tue, Aug 7, 2012 at 12:52 PM, Scott González <scott.gonzalez@gmail.com>wrote:

> Has there been any more discussion outside of this thread?
>
>
> On Fri, May 11, 2012 at 1:53 PM, James Greene <james.m.greene@gmail.com>wrote:
>
>> 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 Tuesday, 7 August 2012 17:57:43 UTC