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

On Mon, Apr 25, 2011 at 11:52 AM, Jonas Sicking wrote:
> 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

The canceling and bubbling the error event scenarios make sense to me.  Thanks for clarifying!

You are correct, we don't want to implement another interface.  What I was proposing is to define a new event type for indexedDB errors not a new interface.  We would still use the same onerror attribute but the event type would be called "IDBError", not "error".  This would allow us to define our own bubbling and canceling behavior on the existing Event interface.

Since, the DOM L3 event "error" type does neither (bubbling and canceling), that seems to be a good reason for us defining a new type (not interface) called IDBError.

Do you see any scenarios where we should support the capture phase for the error event?
I can open a bug if this makes sense.

Israel

Received on Monday, 25 April 2011 22:06:37 UTC