Spent Iterators Should Not Throw an Exception

[Brad Fults]

This is in reference to Brendan's XTech presentation and the docs being
posted on devmo[1].

Exceptions should be used when there is a runtime error, not when a
normal termination condition occurs. When calling it.next() on an
iterator, the return value of that call should indicate the status of
the iterator. The value returned should probably be null, but I'd be
willing to entertain arguments for false, undefined, or something of
the sort.

Throwing an exception to handle a normal case like a spent iterator
will cause developers to litter code with try/catch blocks and create
an enormous amount of unnecessary complexity. Code like the following
should be possible in the spirit of JS and other languages that support
similar constructs:

while ((item = it.next()) !== null)
{
print(item);
}

I apologize in advance if there's a better forum for JS language
discussion and would appreciate a pointer in the appropriate direction.

Thanks.

[1] - http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7

--
Brad Fults
NeatBox

[chris....@gmail.com]

Brad Fults wrote:
> Exceptions should be used when there is a runtime error, not when a
> normal termination condition occurs. When calling it.next() on an
> iterator, the return value of that call should indicate the status of
> the iterator. The value returned should probably be null, but I'd be
> willing to entertain arguments for false, undefined, or something of
> the sort.

But what if null is a valid return value from the iterator? What do you
return when it is exhausted when the iterator can in fact return any
valid value. Throwing an exception is a valid approach in the case I
think.

Another option may be to have a method that indicates the iteration is
complete rather than overloading 'next'.

Chris.
--
http://www.bluishcoder.co.nz

[Mike Shaver]

On 2 Jun 2006 14:45:32 -0700, Brad Fults <bfu...@gmail.com> wrote:
> Throwing an exception to handle a normal case like a spent iterator
> will cause developers to litter code with try/catch blocks and create
> an enormous amount of unnecessary complexity. Code like the following
> should be possible in the spirit of JS and other languages that support
> similar constructs:
>
> while ((item = it.next()) !== null)
> {
> print(item);
> }

The point of iterators is that you would write

for (item in it) { print (item); }

which is much more in the spirit of JS-with-iterators and other
languages (chiefly Python) which have similar iteration protocols.

The StopIteration exception should not be visible to those who are not
manually manipulating iterator objects, or implementing them. (Just
as it's not, other than some transient bugs, visible to scripts using
for/in or for-each/in loops in today's JS1.7, which loops have been
retrofitted to use the iteration protocol internally as well.)

Python's PEP234, which greatly informed the design of JS's iterators,
also considered non-exception termination protocols, and decided to
use StopIteration for a number of reasons
(http://www.python.org/dev/peps/pep-0234/, see the Resolved Issues
section).

Mike

[Brad Fults]

Mike,

Mike Shaver wrote:
> The StopIteration exception should not be visible to those who are not
> manually manipulating iterator objects, or implementing them.

This makes much more sense. Then my objection is not to the
implementation, but to the documentation that uses a try/catch block
around a loop calling next() as an example of using an iterator. The
docs should be clarified to indicate what normal JS developers should
use with regard to iterators as separate from complex manipulation of
iterators.

> Python's PEP234, which greatly informed the design of JS's iterators,
> also considered non-exception termination protocols, and decided to
> use StopIteration for a number of reasons
> (http://www.python.org/dev/peps/pep-0234/, see the Resolved Issues
> section).

I read the alternate options and agree with the conclusions.

Thanks for the clarification.

--
Brad Fults
NeatBox

[Mike Shaver]

On 4 Jun 2006 10:43:23 -0700, Brad Fults <bfu...@gmail.com> wrote:
> Mike Shaver wrote:
> > The StopIteration exception should not be visible to those who are not
> > manually manipulating iterator objects, or implementing them.
>
> This makes much more sense. Then my objection is not to the
> implementation, but to the documentation that uses a try/catch block
> around a loop calling next() as an example of using an iterator. The
> docs should be clarified to indicate what normal JS developers should
> use with regard to iterators as separate from complex manipulation of
> iterators.

I just did a quick edit to hopefully clarify that a bit; cc:ing sheppy
so he can fix whatever I broke, because he's a sweetheart like that.

Mike

[Eric Shepherd]

Well, whoops and all that. I'll take a look at what Mike did and see
if it needs tweaking.

Thanks,

Eric Shepherd
Technical Writer
she...@mozilla.com

On Jun 4, 2006, at 2:05 PM, Mike Shaver wrote:

> On 4 Jun 2006 10:43:23 -0700, Brad Fults <bfu...@gmail.com> wrote:
>> Mike Shaver wrote:
>> > The StopIteration exception should not be visible to those who
>> are not
>> > manually manipulating iterator objects, or implementing them.
>>
>> This makes much more sense. Then my objection is not to the
>> implementation, but to the documentation that uses a try/catch block
>> around a loop calling next() as an example of using an iterator. The
>> docs should be clarified to indicate what normal JS developers should
>> use with regard to iterators as separate from complex manipulation of
>> iterators.
>

[Martin Honnen]

Eric Shepherd wrote:

> Well, whoops and all that. I'll take a look at what Mike did and see
> if it needs tweaking.

I have issues with the second example in
<http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7#Iterators>,
the example introduced with "Here's a simple example of direct iterator
manipulation:".

Currently it has a closing curly brace too much or a second catch clause
is missing, I am not sure. However the code as presented simply gives a
syntax error and does not run at all.

--

Martin Honnen
http://JavaScript.FAQTs.com/

[Martin Honnen]

Eric Shepherd wrote:

> Well, whoops and all that. I'll take a look at what Mike did and see
> if it needs tweaking.

I have issues with the second example in

[Eric Shepherd]

Looks like a glitch that got introduced during a recent edit. I'll
take care of it; thanks for pointing it out.

Eric Shepherd
Technical Writer
she...@mozilla.com

> _______________________________________________
> dev-tech-js-engine mailing list
> dev-tech-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine

[Martin Honnen]

Eric Shepherd wrote:

> Looks like a glitch that got introduced during a recent edit. I'll
> take care of it; thanks for pointing it out.

So you have taken out that additional brace in that example making the
example code syntactically correct. A problem however remains: the code
does not output what the text describes as the StopIteration is thrown
but not caught and that way the output is not as described, instead of
printing "End of record." the code throws the exception "uncaught
exception: StopIteration".

I am not really in a position to guess how the example should look as I
have only read the introduction to the new features and played with the
shell but one way to get the output shown is with

var obj = {name:"Jack Bauer", username:"JackB", id:12345, agency:"CTU",
region:"Los Angeles"};

var it = Iterator(obj);

try {
while (true) {
print(it.next());
}
} catch (err if !(err instanceof StopIteration)) {
print("Unknown error: " + err.message + "\n");
} catch (err if err instanceof StopIteration) {
print("End of record.\n");

[Eric Shepherd]

Hmmm. Yeah, that's new. Used to work as-is. I'll look at
integrating your suggested change. Thanks!

Thanks again,

Eric Shepherd
Technical Writer
she...@mozilla.com

[Mike Shaver]

On 6/5/06, Eric Shepherd <eshe...@mozilla.com> wrote:
> Hmmm. Yeah, that's new. Used to work as-is. I'll look at
> integrating your suggested change. Thanks!

Oops, I just fixed it up to use a catch-all for non-StopIteration exceptions.

Mike