On Fri, Aug 6, 2010 at 5:50 AM, Jeremy Orlow <[email protected]> wrote: > On Fri, Aug 6, 2010 at 2:07 AM, <[email protected]> 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: [email protected] >> ReportedBy: [email protected] >> QAContact: [email protected] >> CC: [email protected], [email protected] >> >> >> 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
