Re: [indexeddb] Missing TransactionInactiveError Exception type for count and index methods

On Tue, Jan 24, 2012 at 12:33 PM, Israel Hilerio <israelh@microsoft.com> wrote:
> On Tuesday, January 24, 2012 12:12 PM, Jonas Sicking wrote:
>> On Tue, Jan 24, 2012 at 10:08 AM, Israel Hilerio <israelh@microsoft.com>
>> wrote:
>> >> >> In addition, the index method in IDBObjectStore uses
>> >> >> InvalidStateError to convey two different meanings: the object has
>> >> >> been removed or deleted and the transaction being used finished.
>> >> >> It seems that it would be better to separate these into:
>> >> >> * InvalidStateError when the source object has been removed or
>> deleted.
>> >> >> * TransactionInactiveError when the transaction being used is inactive.
>> >> >>
>> >> >> What do you think?  I can open a bug if we agree this is the
>> >> >> desired behavior.
>> >> >
>> >> >
>> >> > Did this come out of the discussion here:
>> >> >
>> >> > http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1589.
>> >> > htm
>> >> > l
>> >> >
>> >> > If so, the rationale for which exception type to use is included,
>> >> > although no-one on the thread was deeply averse to the alternative.
>> >> > If it's a different issue can give a more specific example?
>> >>
>> >> Right. I think InvalidStateErr is better, for the reason detailed in
>> >> the above referenced email.
>> >>
>> >> I agree we're using the same exception for two error conditions, but
>> >> I'm not terribly worried that this will make debugging harder for authors.
>> >>
>> >> But I don't feel strongly so if there's a good reason I'm ok with
>> >> changing things.
>> >>
>> >> / Jonas
>> >>
>> >
>> > I agree that InvalidStateErr makes sense here.  The issue we're presenting is
>> the use of one exception for two error conditions.
>> > We just want to remove the ambiguity and cleanup of the language.  We
>> have this issue in the IDBObjectStore.index and IDBTransaction.objectStore
>> methods.
>> >
>> > One alternative could be to just leave "InvalidStateError" and remove the
>> "or" clause from the description.
>> > That would leave us with:
>> >
>> > 1. InvalidStateError - Occurs if a request is made on a source object that
>> has been deleted or removed.
>> >
>> > Alternatively, we could add one more exception to capture the "or" clause:
>> >
>> > 2. TransactionInactiveError - Occurs if the transaction the object store
>> belongs to has finished.
>> >
>> > I'm okay with only doing #1, if you all agree.  This simplifies things and
>> captures the idea stated in the reference email.  Let me know what you think.
>>
>> Hmm.. I think I'm not fully following you. Did you intend for #1 to change
>> normative behavior, or to be an editorial clarification?
>>
>> Simply removing the part after the "or" seems to result in a normative
>> change since nowhere would we say that an exception should be thrown if
>> index() is called after a transaction has finished. I.e. removing it would mean
>> that index() would have to return an IDBIndex instance even when called
>> after the transaction has finished.
>>
>> Maybe the solution is to change the text to something like: "Thrown if the
>> function is called on a source object that has been deleted. Also thrown if the
>> transaction the object store belongs to has finished."
>>
>> / Jonas
>
> Sorry for the confusion.  My assumption for #1 was that it would be okay not to throw an exception
> if a developer were to make a call to IDBObjectStore.index and IDBTransaction.objectStore when
> there is no transaction as long as any requests from those objects would throw TransactionInactiveError.
> This would leave TransactionInactiveError to be thrown by methods that return IDBRequests only.
>
> In Alternative #2, we were proposing to add TransactionInactiveError to the exception list to avoid the
> exception overloading.  It just seems weird to overload InvalidStateError with multiple definitions.
>
> Should we just do #2, then?

Hmm.. the throwing for index() when called was after the transaction
was ended was done on request from you guys as I recall it.

As mentioned in the discussion at [1] I think that
TransactionInactiveError is the wrong exception to throw here.

l really don't understand the problem of throwing the same exception
for two different error conditions. For example IDBObjectStore.put and
IDBObjectStore.add throws a DataError for 7 different error conditions
as enumerated in the bullet list at [2]. And IDBCursor.update throws
InvalidStateError under two different conditions [3]. And any function
which uses structured clones throw DataCloneError for two related but
different error conditions [4].

So I don't see why we couldn't simply keep things as they are now?

[1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1589.html
[2] http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBObjectStore-put-IDBRequest-any-value-any-key
[3] http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBCursor-update-IDBRequest-any-value
[4] http://dev.w3.org/html5/spec/Overview.html#structured-clone

/ Jonas

Received on Tuesday, 24 January 2012 20:49:08 UTC