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

[Scott González]

Has there been any more discussion outside of this thread?


On Fri, May 11, 2012 at 1:53 PM, James Greene <james.m.greene at 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 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
> >
>