- From: Scott González <scott.gonzalez@gmail.com>
- Date: Tue, 7 Aug 2012 13:52:14 -0400
- To: James Greene <james.m.greene@gmail.com>
- Cc: whatwg@whatwg.org, Simon Pieters <simonp@opera.com>
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:52:42 UTC