- From: Křištof Želechovski <giecrilj@stegny.2a.pl>
- Date: Sun, 23 Sep 2007 09:33:06 +0200
The proper way to handle errors is to use language-specific constructs. The window object in Internet Explorer was required to fire error events as a substitute because Visual Basic scripting edition's support for handling errors is lame. It is possible to do it but it is very tedious. Please note that: 1. The handler syntax is different from all other error handlers, including image error handlers, in that it takes three parameters and not one and it does not get the event object at all, 2. The error event is legitimate on several HTML elements where it means something entirely different. Conclusion: I can see no point in reintroducing this feature to the standard. It will only cause confusion. Cheers, Chris -----Original Message----- From: whatwg-bounces@lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Garrett Smith Sent: Saturday, September 22, 2007 10:55 PM To: whatwg at whatwg.org Subject: [whatwg] window.onerror -ancient feature needs upgrade window.onerror There needs to be a way to capture errors on the window. A method that passes an Error to the handler. One possible solution would be to leverage the existing event system: addEventListener( "error", genericErrorEventHandler, false ); function genericErrorEventHandler( errorEvent ) { // What is the argument here? var error = errorEvent.error; }; Grabbing the Error instance off the event seems somewhat unintuitive }E uses that approach. It also leads to switch statements or too much conditional logic. I function genericErrorEventHandler( errorEvent ) { // What is the argument here? var error = errorEvent.error; if( error instanceof EvalError) { }; Maybe someone has a better idea?. would be useful to have a method on the global object to catch errors. addEventListener( "evalerror", genericErrorEventHandler, false ); Garrett -- Programming is a collaborative art.
Received on Sunday, 23 September 2007 00:33:06 UTC