- From: Simon Pieters <simonp@opera.com>
- Date: Fri, 11 May 2012 07:42:48 +0200
- To: "James Greene" <james.m.greene@gmail.com>
- 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 UTC