- From: Kris Zyp <kris@sitepen.com>
- Date: Tue, 02 Feb 2010 21:16:15 -0700
- 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 UTC