W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

RE: [indexeddb] Handling negative parameters for the advance method

From: Israel Hilerio <israelh@microsoft.com>
Date: Mon, 15 Aug 2011 22:27:33 +0000
To: Jonas Sicking <jonas@sicking.cc>
CC: Aryeh Gregor <ayg@aryeh.name>, "public-webapps@w3.org" <public-webapps@w3.org>, Jim Wordelman <jaword@microsoft.com>, "Adam Herchenroether" <aherchen@microsoft.com>, Victor Ngo <vicngo@microsoft.com>
Message-ID: <F695AF7AA77CC745A271AD0F61BBC61E3D200015@TK5EX14MBXC113.redmond.corp.microsoft.com>
On Monday, August 15, 2011 2:22 PM, Jonas Sicking wrote:
> On Mon, Aug 15, 2011 at 10:29 AM, Israel Hilerio <israelh@microsoft.com>
> wrote:
> > On Sunday, August 14, 2011 4:09 PM, Aryeh Gregor wrote:
> >> On Fri, Aug 12, 2011 at 6:16 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >> > Yup. Though I think WebIDL will take care of the handling for when
> >> > the author specifies a negative value. I.e. WebIDL will specify
> >> > what exception to throw, so we don't need to. Similar to how WebIDL
> >> > specifies what exception to throw if the author specifies too few
> >> > parameters, or parameters of the wrong type.
> >>
> >> It doesn't throw an exception -- the input is wrapped.  It basically
> >> calls the
> >> ToUInt32 algorithm from ECMAScript:
> >>
> >> http://dev.w3.org/2006/webapi/WebIDL/#es-unsigned-long
> >>
> >> This behavior is apparently needed for compat, or so I was told when
> >> I complained that it's ridiculous to treat JS longs like C.  It does
> >> have the one
> >> (arguable) advantage that authors can use -1 for "maximum allowed
> value".
> >>
> >> But anyway, yes: if your IDL says unsigned, then your algorithm can't
> >> define behavior for what happens when the input is negative, because
> >> WebIDL will ensure the algorithm never sees a value outside the
> >> allowed range.  If you want special behavior for negative values, you have
> to use a regular long.
> >>
> >
> > I like Areyh's suggestion.  What if we were to keep the parameter as a long
> and specify in the spec that zero and negative values will not advance the
> cursor in any direction.  We could add something like this:
> > "If the count value is less than or equal to zero the iteration will not take
> place."
> > After thinking about this some more, I like this better than having the
> unexpected side effects of passing a negative number to a unsigned long
> parameter.
> >
> > Jonas, what do you think?
> 
> Hmm.. Yeah, I suspect that is the better behavior here. We should probably
> also throw if the number is 0.
> 
> / Jonas

If a developer specifies zero as a value, we could throw an
IDBDatabaseException with a value of NON_TRANSIENT_ERR.
What about doing the same for negative values?

Israel
Received on Monday, 15 August 2011 22:28:04 GMT

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