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

[James Greene]

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.

I personally am interested in adding the stack trace, yes, 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).  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.

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?  I thought they
utilized the "SyntaxError" class but perhaps that's only for "eval()"
calls...? 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 appreciate your continued feedback. Thanks!

Sincerely,
    James Greene




On Fri, May 11, 2012 at 12:42 AM, Simon Pieters <simonp at opera.com> wrote:

> On Thu, 10 May 2012 21:14:23 +0200, James Greene <james.m.greene at gmail.com>
> wrote:
>
>  In my opinion, adding the stack trace to the existing message would be
>> messy, breaks existing developer expectations, and possibly even breaks
>> backward compatibility of specific libraries/functions/**monitoring/etc.
>> in
>> some more extreme situations. If we can't just have the "Error" object
>> itself passed in, I'd much prefer "stack" as a fifth parameter versus
>> unexpected modification of an existing parameter.
>>
>
> Right, "stack" as a fifth parameter was what I suggested.
>
>
>  We can also keep adding parameters to the "window.onerror" invocation till
>> we're blue in the face...
>>
>
> Or only add parameters that solve use cases being presented...
>
>
>  but, in reality, don't we just want all of the
>> properties of the relevant "Error" object?
>>
>
> I don't know, that why I asked what you want.
>
>  I'd really love to *just* have
>>
>> the "Error" object passed (e.g. "window.onerror(function(e) { ... })") but
>> I know that would break backward compatibility, so I didn't propose it.
>>
>
> What do you want for compile errors, which don't have an Error object at
> all?
>
>  It seems to me like "columnNumber" should be added to the "Error" object
>> as
>> a standard (speaking of which: https://github.com/JSFixed/**
>> JSFixed/issues/51 <https://github.com/JSFixed/JSFixed/issues/51>)
>> *instead of* adding it as yet another parameter to the already ugly
>>
>> "window.onerror", and then just pass the "Error" object so devs can get
>> whatever information they want from it.
>>
>
> What about compile error?
>
>
>  But, if it's a security thing, I
>> guess I'm willing to accept that....
>>
>
> The security thing is solvable either way.
>
>
> --
> Simon Pieters
> Opera Software
>