The JS onerror event and the ECMA Standard
On Mon, Jan 5, 2009 at 7:42 AM, Michael Ratcliffe <michael at ratcliffefamily.org> wrote:
Are there any plans to make onerror part of the ECMA standard and, if so, is it possible for me to suggest adding an additional item that should be accessible from the onerror handler? I would suggest that a fourth parameter be passed to the onerror handler, which is the error object from the time the error is triggered. This would allow access to the call stack from within the handler and would be an invaluable in uncovering complex bugs.
No, window.onerror would be standardized by the W3C or WHATWG, since it's not itself a language feature but rather a part of one embedding context -- albeit a very popular one! Standardizing call stack representation could be in the scope of this group and the ECMA process, if needed.
Mike
On 2009-01-05, at 07:42EST, Michael Ratcliffe wrote:
I have a question about the Javascript onerror event ... I know it
is not part of the ECMA standard and that is my point.
I would sure like to see a more comprehensive error-handling
capability in the language. Something that would let me bind handlers
to errors along the lines of Lisp's: lambda-the-ultimate.org/node/1544
Because the most common use of JS is in a web browser, and because
your JS can be entered 'randomly' (in response to user events), it
would be very nice if there were an in-language way to specify a
default handler binding for error classes.
This issue plagues ActionScript as well: bugs.adobe.com/jira/browse/FP
There was some discussion about onerror and its parameters a few months ago on the WHATWG list: www.nabble.com/window.onerror--ancient-feature-needs-upgrade-td153874 21.html
Best Mike Wilson
I have a question about the Javascript onerror event ... I know it is not part of the ECMA standard and that is my point.
I have a complex web app used by some large corporations. This web app is used to create online tests for their customers (members of the public). There can be hundreds of factors that can come together to create a JavaScript bug ... UA, popup blockers, path taken, popup window or not, computers regional settings, browser settings etc., etc.
It is obviously not very professional for us to ask a corporation to have members of the public install debugging tools to try and isolate a bug, but currently that is the situation that a lot of us face. An increasing number of devs are turning to the method of trapping the error and logging as much info as possible using AJAX.
Are there any plans to make onerror part of the ECMA standard and, if so, is it possible for me to suggest adding an additional item that should be accessible from the onerror handler? I would suggest that a fourth parameter be passed to the onerror handler, which is the error object from the time the error is triggered. This would allow access to the call stack from within the handler and would be an invaluable in uncovering complex bugs.
At the moment there is no possible way to do access the call stack or any other tracing info in the event of an error ... almost every other modern language exposes this information.