I'd rather get an Error-like duck-typed object with this shell info for
cross-domain requests than to not get a real Error object when the
unhandled error *is* from the same origin.
Adding the trace as another new argument to `window.onerror` is certainly
an option but the parameter list is
Can we just add a new event that takes an event object instead of a huge
list of arguments? :)
On Fri, Jul 12, 2013 at 11:30 AM, James Greene james.m.gre...@gmail.comwrote:
I'd rather get an Error-like duck-typed object with this shell info for
cross-domain requests than to not get a real
I'd love that! Perhaps similar to what Node.js did with their
`uncaughtException`
event http://nodejs.org/api/process.html#process_event_uncaughtexception?
Sincerely,
James Greene
On Fri, Jul 12, 2013 at 1:40 PM, Elliott Sprehn espr...@chromium.orgwrote:
Can we just add a new event that
On Tue, 05 Feb 2013 08:20:27 +0100, Elliott Sprehn espr...@chromium.org
wrote:
On Mon, Feb 4, 2013 at 5:44 PM, Oliver Hunt oli...@apple.com wrote:
...
That's tricky - what is your stack trace? You can very easily end up
leaking private information across frames.
window.onerror is
On 2/4/13, Nathan Broadbent nathan@gmail.com wrote:
Hi,
Hi Nathan -
The current information passed to window.onerror rarely provides
sufficient information to find the cause of the error. The column
That's putting it mildly.
number argument will be a big step forward, but a stack trace
On Feb 4, 2013, at 2:40 PM, Garrett Smith dhtmlkitc...@gmail.com wrote:
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.
Why not?
That's something lost in the mists of time, however
On Mon, Feb 4, 2013 at 5:44 PM, Oliver Hunt oli...@apple.com wrote:
...
That's tricky - what is your stack trace? You can very easily end up
leaking private information across frames.
window.onerror is triggered across non-same origin frames?
- E
On Thu, 29 Nov 2012 04:35:21 +0100, Ian Hickson i...@hixie.ch wrote:
Having the exception object, if any, in the onerror callback, seems
reasonable, and would indeed limit how many more arguments we may have to
add over the years. It seems that providing it as an argument would be
better than
On Tue, 8 May 2012, James Greene wrote:
The problem [with window.onerror is] that this mechanism does not allow
us to inspect the pertinent Error object at all: it only provides us
with three arguments at invocation time: message (string), fileName
(string), and lineNumber (number). These
Has there been any more discussion outside of this thread?
On Fri, May 11, 2012 at 1:53 PM, James Greene james.m.gre...@gmail.comwrote:
Alright... so what's next? I'm assuming this needs further discussion with
other WHATWG members chiming in. If I can help, please let me know. I'd
like to
Simon emailed me personally to answer my last question about what's next: We
wait for the editor to process this thread. It might take a while, but
he'll get to it.
Other than that, there haven't been any discussions that I've been privy to.
Sincerely,
James Greene
On Tue, Aug 7, 2012 at
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
On Fri, 11 May 2012 17:14:00 +0200, James Greene
james.m.gre...@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
Alright... so what's next? I'm assuming this needs further discussion with
other WHATWG members chiming in. If I can help, please let me know. I'd
like to see this request through.
Sincerely,
James Greene
On Fri, May 11, 2012 at 12:26 PM, Simon Pieters sim...@opera.com wrote:
On Fri,
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
On Thu, 10 May 2012 21:14:23 +0200, James Greene
james.m.gre...@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
On Wed, 09 May 2012 03:56:29 +0200, James Greene
james.m.gre...@gmail.com wrote:
Full proposal details:
https://gist.github.com/3ded0f6e7f0a658b9394
P.S. I had no idea what product to file this under in the W3C Bugzilla,
so it has NOT been filed there.
On Wed, 09 May 2012 03:56:29 +0200, James Greene
james.m.gre...@gmail.com wrote:
Full proposal details:
https://gist.github.com/3ded0f6e7f0a658b9394
quoting the above (revision
https://gist.github.com/3ded0f6e7f0a658b9394/51e980f0474c255738a3b6ecf003bb6cb30db49c
):
# Proposal:
Full proposal details:
https://gist.github.com/3ded0f6e7f0a658b9394
P.S. I had no idea what product to file this under in the W3C Bugzilla,
so it has NOT been filed there. I HAVE posted a new topic to the Forums but
it is still awaiting moderator approval.
Sincerely,
James Greene
19 matches
Mail list logo
