On Thu, 10 May 2012 21:14:23 +0200, James Greene
<[email protected]> 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
