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: Jeremy Orlow <jorlow@chromium.org>
Date: Fri, 6 Aug 2010 13:50:25 +0100
Message-ID: <AANLkTinF_dfrpdDE5ZPLE_PvMtvRqvSoBrQLKUG6_0b+@mail.gmail.com>
To: public-webapps@w3.org, Pablo Castro <Pablo.Castro@microsoft.com>
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.

Received on Friday, 6 August 2010 12:51:15 UTC

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