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

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 22 Feb 2011 15:00:02 -0800
Message-ID: <AANLkTim-43_nOqoLzdSx-qCfhZePmmsff931UU_edRe8@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: David Grogan <dgrogan@chromium.org>, public-webapps@w3.org
On Tue, Feb 22, 2011 at 2:48 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Sat, Feb 19, 2011 at 8:46 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Fri, Feb 18, 2011 at 5:58 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
>> > If an exception is unhanded in an IDB event handler, we abort the
>> > transaction.  Should we continue firing the other handlers when this
>> > happens, though?
>>
>> What do you mean by "other handlers"? The other handlers for that same
>> event? If so, I would say we should so that we're sticking with the
>> DOM Events spec.
>>
>> > And should preventDefault prevent the abort?
>>
>> preventDefault usually prevents the default action of the event. The
>> abort isn't the default action, so I would say no. (It also seems a
>> bit weird that calling preventDefault on a success event would prevent
>> an abort).
>
> So if any of the event handlers doesn't catch an exception, there's no way
> to keep the transaction from aborting?

No. Your opportunity to prevent the abort is by catching the
exception. Once you don't then that's equivalent to an explicit call
to .abort(). Similarly, if you don't call .preventDefault() in an
error handler, or do call .abort(), there is no way to later prevent
the abort.

/ Jonas
Received on Tuesday, 22 February 2011 23:01:06 GMT

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