Re: [IndexedDB] Throwing when *creating* a transaction
Removed!
On Mon, Oct 31, 2011 at 11:15 PM, Israel Hilerio wrote:
> IE is okay with removing this from the spec.
>
>
>
> Israel
>
>
>
> On Monday, October 31, 2011 5:06 PM, Joshua Bell wrote:
>
> From: jsb...@google.com [mailto:jsb...@google.com] On Behalf Of Joshua Bell
> Sent: Monday, October 31, 2011 5:06 PM
> To: Webapps WG
> Subject: Re: [IndexedDB] Throwing when *creating* a transaction
>
>
>
> On Mon, Oct 31, 2011 at 3:02 PM, Jonas Sicking wrote:
>
> Hi guys,
>
> Currently the spec contains the following sentence:
>
> "Conforming user agents must automatically abort a transaction at the
> end of the scope in which it was created, if an exception is
> propagated to that scope."
>
> This means that the following code:
>
> setTimeout(function() {
> doStuff();
> throw "booo";
> }, 10);
>
> function doStuff() {
> var trans = db.transaction(["store1"], IDBTransaction.READ_WRITE)
> trans.objectStore("store1").put({ some: "value" }, 5);
> }
>
> is supposed to abort the transaction. I.e. since the same callback (in
> this case a setTimeout callback) which created the transaction later
> on throws, the spec says to abort the transaction. This was something
> that we debated a long time ago, but my recollection was that we
> should not spec this behavior. It appears that this was never removed
> from the spec though.
>
> One reason that I don't think that we should spec this behavior is
> that it's extremely tedious and error prone to implement. At every
> point that an implementation calls into javascript, the implementation
> has to add code which checks if an exception was thrown and if so,
> check if any transactions were started, and if so abort them.
>
> I'd like to simply remove this sentence. Any objections?
>
>
>
> No objections here. Chrome doesn't currently implement this behavior.
>
>
>
> Note, this does *not* affect the aborting that happens if an exception
> is thrown during a "success" or "error" event handler.
>
> / Jonas
>
>
RE: [IndexedDB] Throwing when *creating* a transaction
IE is okay with removing this from the spec.
Israel
On Monday, October 31, 2011 5:06 PM, Joshua Bell wrote:
From: jsb...@google.com [mailto:jsb...@google.com] On Behalf Of Joshua Bell
Sent: Monday, October 31, 2011 5:06 PM
To: Webapps WG
Subject: Re: [IndexedDB] Throwing when *creating* a transaction
On Mon, Oct 31, 2011 at 3:02 PM, Jonas Sicking
mailto:jo...@sicking.cc>> wrote:
Hi guys,
Currently the spec contains the following sentence:
"Conforming user agents must automatically abort a transaction at the
end of the scope in which it was created, if an exception is
propagated to that scope."
This means that the following code:
setTimeout(function() {
doStuff();
throw "booo";
}, 10);
function doStuff() {
var trans = db.transaction(["store1"], IDBTransaction.READ_WRITE)
trans.objectStore("store1").put({ some: "value" }, 5);
}
is supposed to abort the transaction. I.e. since the same callback (in
this case a setTimeout callback) which created the transaction later
on throws, the spec says to abort the transaction. This was something
that we debated a long time ago, but my recollection was that we
should not spec this behavior. It appears that this was never removed
from the spec though.
One reason that I don't think that we should spec this behavior is
that it's extremely tedious and error prone to implement. At every
point that an implementation calls into javascript, the implementation
has to add code which checks if an exception was thrown and if so,
check if any transactions were started, and if so abort them.
I'd like to simply remove this sentence. Any objections?
No objections here. Chrome doesn't currently implement this behavior.
Note, this does *not* affect the aborting that happens if an exception
is thrown during a "success" or "error" event handler.
/ Jonas
Re: [IndexedDB] Throwing when *creating* a transaction
On Mon, Oct 31, 2011 at 3:02 PM, Jonas Sicking wrote:
> Hi guys,
>
> Currently the spec contains the following sentence:
>
> "Conforming user agents must automatically abort a transaction at the
> end of the scope in which it was created, if an exception is
> propagated to that scope."
>
> This means that the following code:
>
> setTimeout(function() {
> doStuff();
> throw "booo";
> }, 10);
>
> function doStuff() {
> var trans = db.transaction(["store1"], IDBTransaction.READ_WRITE)
> trans.objectStore("store1").put({ some: "value" }, 5);
> }
>
> is supposed to abort the transaction. I.e. since the same callback (in
> this case a setTimeout callback) which created the transaction later
> on throws, the spec says to abort the transaction. This was something
> that we debated a long time ago, but my recollection was that we
> should not spec this behavior. It appears that this was never removed
> from the spec though.
>
> One reason that I don't think that we should spec this behavior is
> that it's extremely tedious and error prone to implement. At every
> point that an implementation calls into javascript, the implementation
> has to add code which checks if an exception was thrown and if so,
> check if any transactions were started, and if so abort them.
>
> I'd like to simply remove this sentence. Any objections?
>
No objections here. Chrome doesn't currently implement this behavior.
> Note, this does *not* affect the aborting that happens if an exception
> is thrown during a "success" or "error" event handler.
>
> / Jonas
>
>
[IndexedDB] Throwing when *creating* a transaction
Hi guys,
Currently the spec contains the following sentence:
"Conforming user agents must automatically abort a transaction at the
end of the scope in which it was created, if an exception is
propagated to that scope."
This means that the following code:
setTimeout(function() {
doStuff();
throw "booo";
}, 10);
function doStuff() {
var trans = db.transaction(["store1"], IDBTransaction.READ_WRITE)
trans.objectStore("store1").put({ some: "value" }, 5);
}
is supposed to abort the transaction. I.e. since the same callback (in
this case a setTimeout callback) which created the transaction later
on throws, the spec says to abort the transaction. This was something
that we debated a long time ago, but my recollection was that we
should not spec this behavior. It appears that this was never removed
from the spec though.
One reason that I don't think that we should spec this behavior is
that it's extremely tedious and error prone to implement. At every
point that an implementation calls into javascript, the implementation
has to add code which checks if an exception was thrown and if so,
check if any transactions were started, and if so abort them.
I'd like to simply remove this sentence. Any objections?
Note, this does *not* affect the aborting that happens if an exception
is thrown during a "success" or "error" event handler.
/ Jonas
