- From: Simon Pieters <simonp@opera.com>
- Date: Fri, 11 May 2012 19:26:57 +0200
- To: "James Greene" <james.m.greene@gmail.com>
- Cc: whatwg@whatwg.org
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:27:38 UTC