- From: Glenn Maynard <glenn@zewt.org>
- Date: Tue, 20 Mar 2012 18:09:21 -0500
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Yonathan <yonathan@gmail.com>, public-webapps@w3.org
- Message-ID: <CABirCh-wuKRGANJzvmxp-HFArm4-XwFdRthOad35VZa74cX8yA@mail.gmail.com>
"Create a transaction" step 4 says "create a transaction", whcih is recursive. The bolded phrase "create a transaction" is never used. It looks like this is out of sync: the phrase actually used is "steps for creating a transaction". They should match exactly, to allow searching. On Mon, Mar 19, 2012 at 11:49 PM, Jonas Sicking <jonas@sicking.cc> wrote: > > 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. > But inside *other* events, like onclick, not from onsuccess. From the beginning of this thread, it sounds like listening for onsuccess may even be uncommon, and probably more often used for non-database things, like updating a progress bar (where aborting the transaction doesn't make sense). In the common case, you have to handle errors yourself: e.onclick = function() { trans = db.transaction(...); try { trans.objectStore(...).put(x()); trans.objectStore(...).put(y()); } catch(e) { trans.abort(); throw e; } } I don't think it helps to do this magically in an uncommon case, when everyone needs to be in the habit of doing it manually in the common case anyway. It just seems confusing and arbitrary. (Aborting due to exceptions from synchronous callbacks is fine, though, since it's consistent: *all* requests on the transaction happen inside it.) -- Glenn Maynard
Received on Tuesday, 20 March 2012 23:09:49 UTC