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

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

From: <bugzilla@jessica.w3.org>
Date: Fri, 06 Aug 2010 01:07:03 +0000
To: public-webapps@w3.org
Message-ID: <bug-10302-2927@http.www.w3.org/Bugs/Public/>

           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.

[1] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0231.html

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Friday, 6 August 2010 01:07:05 UTC

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