- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 6 Aug 2010 10:59:53 -0700
- 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