W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model

From: Simon Pieters <simonp@opera.com>
Date: Mon, 14 Feb 2011 21:41:55 +0100
To: "Jonas Sicking" <jonas@sicking.cc>
Cc: "Jeremy Orlow" <jorlow@chromium.org>, public-webapps@w3.org
Message-ID: <op.vqwuf5znidj3kv@simon-pieterss-macbook.local>
On Mon, 14 Feb 2011 19:59:37 +0100, Jonas Sicking <jonas@sicking.cc> wrote:

> In many of these cases other things than programming errors are likely
> the cause of the error. In most of what you are listing network errors
> are likely the most common source of errors.

Yeah. (I got the list by searching for "named error" in the spec, which  
matched a bunch of stuff that fires error events, but the list is very  
likely not exhaustive.)


> Note again that the IndexedDB errors we are talking about here are
> semantically very similar to exceptions. The only reason we're not
> making them exceptions is that we can't since exceptions would require
> synchronous IO. So I would argue that consistency with exceptions is
> more important that consistency with much of what you list above.

OK.


> That said, maybe we should fire window.onerror for many of the things
> that you list above.

Could you file a bug to that effect?


> I'll repeat my question which you left
> unanswered:
>
> What is the use case for window.onerror that you had in mind which
> would require that we *don't* fire window.onerror for IndexedDB
> errors?

No use case for not doing it. I'm fine with doing it if there's a use case  
that warrants doing it, and we can keep the platform consistent with  
errors elsewhere.

cheers
-- 
Simon Pieters
Opera Software
Received on Monday, 14 February 2011 20:42:32 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT