This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10302 - Introduce exception handlers at the transaction/database scope
Summary: Introduce exception handlers at the transaction/database scope
Status: RESOLVED DUPLICATE of bug 11348
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Nikunj Mehta
QA Contact: public-webapps-bugzilla
Depends on:
Reported: 2010-08-06 01:07 UTC by Pablo Castro
Modified: 2010-11-22 15:08 UTC (History)
3 users (show)

See Also:


Description Pablo Castro 2010-08-06 01:07:01 UTC
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.

Comment 1 Jeremy Orlow 2010-11-22 15:08:55 UTC
Oops, I didn't see this when I created my other bug.  The other one is more precise about the solution though, so I think it's best to leave it open.

*** This bug has been marked as a duplicate of bug 11348 ***