W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: [IndexedDB] Detailed comments for the current draft

From: Kris Zyp <kris@sitepen.com>
Date: Tue, 02 Feb 2010 21:16:15 -0700
Message-ID: <4B68F88F.5040605@sitepen.com>
To: Pablo Castro <Pablo.Castro@microsoft.com>
CC: Jeremy Orlow <jorlow@chromium.org>, Nikunj Mehta <nikunj@o-micron.com>, "public-webapps@w3.org" <public-webapps@w3.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 


On 2/2/2010 8:37 PM, Pablo Castro wrote:
>>>> d.      3.2.4.2: 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
SitePen
(503) 806-1841
http://sitepen.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkto+I4ACgkQ9VpNnHc4zAzi+wCgqbHM+uYRUlgE8fX4br88IkFx
k+AAoJRQ9aFmGx7hicGolb2jEnzxHJy8
=j7lx
-----END PGP SIGNATURE-----
Received on Wednesday, 3 February 2010 04:17:27 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:36 GMT