Re: [IndexedDB] Detailed comments for the current draft

Hash: SHA1

On 2/2/2010 8:37 PM, Pablo Castro wrote:
>>>> d. in our experiments writing application code, the
fact that this method throws an exception when an item is not found is
quite inconvenient. It would be much natural to just return undefined,
as this can be a primary code path (to not find something) and not an
exceptional situation. Same for 3.2.5, step 2 and 3.2.6 step 2.
>>> > > I am not comfortable specifying the API to be dependent on the
separation between undefined and null. Since null is a valid return
value, it doesn't make sense to return that either. The only safe
alternative appears to be to throw an error.
> What do other folks think about this? I understand your concern, but it
makes writing regular code really noisy as you need try/catch blocks to
handle non-exceptional situations.
I agree with returning undefined for non-existent keys. JavaScript
objects are key-value sets, and they return undefined when you attempt
to access a non-existent key. Consistency suggests that JavaScript
database should do the same. I also agree with Pablo's point that
users would be likely to turn to doing an exists() and get() call
together, which would most likely be more expensive than a single get().

- -- 
Kris Zyp
(503) 806-1841
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

Received on Wednesday, 3 February 2010 04:17:27 UTC