Re: [IndexedDB] Discrepancies with the Event type of error in section 4.12

On Mon, Apr 25, 2011 at 9:18 AM, Israel Hilerio <israelh@microsoft.com> wrote:
> Step 3 in Section 4.12, "Fire an error event", on the latest editor draft stipulates that:
>
> "3. Dispatch an event at request. The event must use the Event interface and have its type set to "error". The event does bubble and is cancelable. ..."
>
> Looking over the DOM L3 event spec, the type "error" Event doesn't buble and is not cancelable [1].
>
> Pablo and I are not sure about the benefits of having the error event be cancelable.  In our experience, canceling and event implies that the reason for this error can be modified or altered.  Leaving this statement would imply that if a developer were to receive a NOT_ALLOWED_ERR she could cancel the error and things would work.

Note that 'cancelable' has a specific defined meaning different from
the one you describe above. Cancelling a event is done by calling
preventDefault() and means that the events "default action" is not
executed. In the case of IndexedDB the default action is to abort the
transaction (as defined by step 3).

So in other words, if we want to allow users to catch database errors
and prevent them from aborting the transaction, which I assume we do,
then we need to keep the event cancelable.

> The same question applies to bubbling.  What is the intent of bubbling an error?  For example, if a developer tries to add an object to an objectStore and he fails, where should the event bubble to: the transaction, the database, etc.?  The bubbling hierarchy doesn't seem to be clearly defined.  It would be great to clarify the scenarios here.

The intent is to allow attaching a event handler to just the
transaction object and catch all errors happening in the scope of the
transaction. For example is a page uses a transaction to insert 1000
entries into a database, it'd be nice to have a single point of
attaching error handling code rather than having to do it on every
individual Request object.

Similarly, by allowing the event to bubble up to the database object,
event handlers could be attached there that span multiple
transactions.

This is similar to how exceptions work. Exceptions walk up the call
chain and allow you to attach error handling code higher up in the
call stack which handles all errors in a given execution path. Rather
than at each low-level action have to hook up error handling code.

> Adding bubbling to an event of type "error" would require us to introduce a new event type, "IDBError".  The reason is that we probably don't want to overload the existing DOM L3 type definition for error.  There is a precedence for this in the SVG spec, the SVGError type.

I don't see why making the event implement an additional interface
would improve the situation. We'd still have to implement the Event
interface just like DOM-Events, since all events have to implement
Event.

But I also don't think it's a problem that we fire an event that is
similar to the one DOM-Events define, even though it uses the same
name. The event isn't fired on the same objects and so no collisions
should occur.

I do agree it's somewhat unfortunate that some "error" events bubble,
but others don't. But I think it'd be even worse to use a different
event name, or to make the event not bubble.

> A couple of questions:
> * Do we agree that errors shouldn't be cancelable?

I think we should leave it cancelable as to allow pages to do error
handling and not abort the transaction.

> * How do we feel about bubbling?  If we want to keep it, what are the main scenarios and what would the event hierarchy look like?

The propagation part is defined in step 3. During the bubbling phase
handlers at the IDBRequest are run first, then the ones at the
IDBTransaction and then finally at the IDBDatabase.

> * Assuming bubbling, how do you feel about adding a new event type called IDBError to capture the non-cancelable and bubbling behavior of this event?

I don't see what problem that solves?

/ Jonas

Received on Monday, 25 April 2011 18:53:24 UTC