W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [Bug 10302] New: Introduce exception handlers at the transaction/database scope

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 6 Aug 2010 10:59:53 -0700
Message-ID: <AANLkTikeUM-FLdkkm+15NaiJRrchRKPEsV4suuzt=ZDi@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: public-webapps@w3.org, Pablo Castro <Pablo.Castro@microsoft.com>
On Fri, Aug 6, 2010 at 5:50 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Fri, Aug 6, 2010 at 2:07 AM, <bugzilla@jessica.w3.org> wrote:
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10302
>>           Summary: Introduce exception handlers at the
>>                    transaction/database scope
>>           Product: WebAppsWG
>>           Version: unspecified
>>          Platform: All
>>        OS/Version: All
>>            Status: NEW
>>          Severity: normal
>>          Priority: P2
>>         Component: Indexed Database API
>>        AssignedTo: nikunj.mehta@oracle.com
>>        ReportedBy: pablo.castro@microsoft.com
>>         QAContact: member-webapi-cvs@w3.org
>>                CC: mike@w3.org, public-webapps@w3.org
>> In many cases error handling will the same for most database access points
>> throughout an application, so having a hierarchy of error handlers would
>> have a
>> good effect in reducing redundant setup of error handlers all over the
>> code.
>> As proposed by Jonas we could have operation-, transaction- and
>> database-scoped
>> error handlers. I'm not sure about tying up .preventDefault() to wether
>> the
>> trasaction gets aborted because you may just want to stop the event from
>> bubbling, but we can discuss this when we come up with the actual write up
>> for
>> this for the spec.
>> Snippet from relevant thread[1] copied below.
>> >> > Somewhat unrelated, but I wonder if we should consider a global (per
>> >> > database session) error handler or something like that. Database operations
>> >> > are just too granular, so maybe the usual deal where you setup an error
>> >> > handler per-operation is not the right thing to do.
>> >>
>> >> This is a great idea. What we could do is to first fire the 'error'
>> >> event on the IDBRequest. If .preventDefault() is not called, we'll
>> >> fire an 'error' event on the IDBTransaction. If .preventDefault()
>> >> still hasn't been called, we fire an 'error' event on the IDBDatabase.
>> >> If .preventDefault() *still* hasn't been called, we roll back the
>> >> transaction.
>> >>
>> >> This is very similar to error handling in Workers. It might be overly
>> >> complex implementation wise, but it does seem like a nice API for
>> >> authors.
> Interesting.  So I assume that when we talk about bubbling, we're saying
> that we'd go up the chain of what spawned the object.  For example,
> IDBObjectStore would raise (if appropriate) to just the IDBTransaction
> object that spawned it, correct?  And even if the IDBTransaction object that
> spawned it were created implicitly by IDBDatabase.objectStore, we still
> would, right?
> If so, SGTM.

Yeah, the way I initially described it was different, but the more I
think about it, the more I think we should set up a "real" event
propagation path. So the error event will first go through a capture
phase from the IDBDatabase -> IDBTransaction -> IDBRequest and then a
bubble phase IDBRequest -> IDBTransaction -> IDBDatabase (technically
I think that at the IDBRequest it's in the target phase, not any of
the other phases).

I wasn't envisioning including IDBObjectStore or IDBIndex in the
chain. Is there a reason to? If so, would we also include IDBCursor?

/ Jonas
Received on Friday, 6 August 2010 18:00:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:10 UTC