W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2004

[whatwg] window.onerror

From: Jim Ley <jim.ley@gmail.com>
Date: Mon, 30 Aug 2004 00:24:49 +0100
Message-ID: <851c8d3104082916244f586dc4@mail.gmail.com>
On Mon, 30 Aug 2004 00:51:54 +0200, Olav Junker Kj?r <olav at olav.dk> wrote:
> Jim Ley wrote:
> > The next is to require ECMAScript Ed.3 (or potentially just the
> > limited version for mobiles)  this will give everyone try/catch
> > abilities so you won't need to worry about onerror, this I certainly
> > think would be sensible.
> 
> The problem is if you want to have a global catch-all error handling,
> e.g. because you want to post an error report back to the server and
> show a custom error message for the user.

To what end?  you can't reliably post back a message in result of a
script error - so there's no way the server can know of one (this
should be obvious of course since the script could error again in
whatever mechanism you used to post back to the server), equally
showing a custom message will never be reliable (although of course
it's more reliable that posting back to server)   Structured error
handling is a much more sensible approach than blinding putting all
errors into an onerror element.

> Since there is no "main" function in a webapp, you need a try-catch in
> every script block and event handler. 

Indeed, you see this as a problem?  You certainly can't do graceful
degradation of your scripts without this...

>This is not very clean. Also,
> errors may be generated from other sources than javascript, e.g. if a
> script or img does not load correctly. 

Ah sorry, you're discussing the two sorts of onerror events (the
window and img object ones)  I wasn't talking about the img one at
all, certainly that could be specified usefully, the script one
however I do not think is useful as defined backwards compatibly.

Jim.
Received on Sunday, 29 August 2004 16:24:49 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:36 UTC