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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Saturday, September 22, 2007 10:55 PM
To: [EMAIL PROTECTED]
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.


Reply via email to