- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 19 Mar 2012 21:49:05 -0700
- 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(...); trans.objectStore(...).put(...); doStuff(); trans.objectStore(...).put(...); if doStuff fails, the transaction still commits though with partial data. However it would be equally unfortunate if function writeSomeData() { trans = db.transaction(...); trans.objectStore(...).put(...); } writeSomeData(); ... lots of code here ... doSomethingThatThrows(); 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