W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

(wrong string) €™t the best for writes

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 19 Mar 2012 21:49:05 -0700
Message-ID: <CA+c2ei8whoo5uup_ZFis+haQ-nk3t=8LxZBRqqdn9dNrFJDN6A@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Yonathan <yonathan@gmail.com>, public-webapps@w3.org
On Mon, Mar 19, 2012 at 7:01 PM, Glenn Maynard <glenn@zewt.org> wrote:
> Unrelated:
> "If an exception was propagated out from any event handler while dispatching
> the event in step 3, abort the transaction by following the steps for
> aborting a transaction using transaction as transaction parameter, and
> AbortError as error."
> Exceptions don't propagate out of event handlers.

You mean that you currently can't measure if an exception has
propagated out of an event handler? Event handlers can certainly have
errors in them that cause exceptions to be thrown from them, but you
indeed can't measure that currently.

> APIs shouldn't do things
> with events that can't be done in JavaScript using dispatchEvent. If we
> really want to vary behavior depending on whether an exception was thrown
> from an event handler, that should be specified by DOM4 and exposed to JS.

Yup, I definitely think we should add this to DOM4 event handling.

> It also seems inconsistent: the transaction is aborted if code fails inside
> onsuccess, but not if it fails almost anywhere else, which seems much more
> likely anyway. I don't think anything else on the platform has special
> error handling like this; I'd recommend just removing it.

What do you mean by "anywhere else"? Most transaction handling will be
inside event handlers.

There is one exception however, the context where a transaction is
created. It's definitely unfortunate that for something like:

trans = db.transaction(...);

if doStuff fails, the transaction still commits though with partial
data. However it would be equally unfortunate if

function writeSomeData() {
  trans = db.transaction(...);

... lots of code here ...

caused the transaction to be aborted. We can solve this by making
transaction() take a callback which is synchronously called. If an
exception propagates out of the callback then the transaction is
aborted. However this results in fairly ugly syntax. I think adding
something like that is something we should consider for v2 for people
that want extra security in their code.

/ Jonas
Received on Tuesday, 20 March 2012 04:50:04 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:39 UTC