W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2012

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

From: Simon Pieters <simonp@opera.com>
Date: Fri, 11 May 2012 07:42:48 +0200
To: "James Greene" <james.m.greene@gmail.com>
Message-ID: <op.wd4p5m03idj3kv@simons-macbook-pro.local>
Cc: whatwg@whatwg.org
On Thu, 10 May 2012 21:14:23 +0200, James Greene  
<james.m.greene@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)
> *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
Received on Friday, 11 May 2012 05:43:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:08 GMT