Exception handling vs. hasNext()

[Garrett Smith]

On Nov 17, 2007 5:50 AM, Brendan Eich <brendan at mozilla.org> wrote:
> On Nov 16, 2007, at 5:30 PM, Garrett Smith wrote:
>
> > Which is better?
> >
> > var nodes : int;
> > var widgetMap = Widget.instances; // a map.
> > var it:Iterator<string> = widgetMap.getKeys();
> >
> >  -- this: --
> >
> > try {
> >   widgetMap.get(it.next()).hide();
> > }
> > catch(Exception e) {
> >   if(e instanceof StopIteration) {
> >
> >   }
> > }
> >
> >
> >  -- or this: --
> >
> > while(it.hasNext()) {
> >   widgetMap.get(it.next()).hide();;
> > }
>
> Neither. This is best:
>
> for each (w in widgetMap)
>      w.hide();
>
> But your two examples are not equivalent. The first calls the
> iterator exactly once, the second loops over all keys. I'm asuming
> widgetMap.get(key) returns the corresponding widget value, so for-
> each-in is the way to loop, not for-in (and never while).
>
Yep, I typed that up @ wk. My brain was still holding some PHP code
and other irrelevant things (my dislike for PHP, food, wanting to
lift, and other topics that may be less relevant).

So... I want to iterate over the keys in a Map.

I would not like to iterate over properties of the map (and it's
prototype); so I'm pretty sure that for in (or for each) is not what I
want. I want to iterate over the key (not object properties).

Kris, it looks like in your example, there's no option for handling
the loop normally:

while (true) {
   try {
       log(consumer.next();
   } catch (exception) {
       if (exception instanceof StopIteration) {
       } else {
           throw exception;
       }
   }
}

I see how normal termination is handled via a try catch, with a
conditional if clause in the catch. What I fail to see is why this is
better than hasNext/next paradigm.

It looks like the reasons for omitting hasNext are:
1) Python does it
2) using try/catch would be faster
3) harder to keep clean with next/hasNext pattern.
Reason 1 isn't a reason for omitting hasNext, is it?
Reason 2 is just copying Python's poor reasoning.
Reason 3 has not yet been shown to be true in any way.

I thought the purpose of exception handling was to handle exceptional
conditions.

Does the new Iterator is requires the use of try/catch in a way that
is appropriate?

If so, why?

In ES3, I use hasOwnProperty in a for/in loop over an object's
properties. Not the prettiest thing, but at least it requires no
exception handling.

How is it possible to iterate over the keys in a Map? I'd like to
avoid using try/catch, unless something in the loop body might require
it, and in that case, I'll want to be very clear on what might throw
an exception, how, and why, as well as provide correct handling of
that exception. Is there a way to get a maps keys as an Array?

I've seen APIs of popular JS libraries swallow exceptions. For
example, YUI's Connection Manager used to do this on the callback
handler, silently swallowing any error that I, as a user of that API,
might throw (painful).  I'm wondering if providing an API that
requires try/catch for non-exceptional conditions cheapens the nature
of exception handling. I mean, won't developers say "oh, it's just a
normal exception, we can ignore it."

Garrett

> As in Python, you rarely have to get or make an iterator explicitly;
> you almost never have to catch StopIteration.
>
> /be
>
>



-- 
Programming is a collaborative art.