> Quinn Dunkan <quinn / envy.ugcs.caltech.edu> writes:
> 
> > Well, since failure is a fundamental concept common to almost all
> > methods,
> >... 
> > an exception
> 
> I got the impression that this failure return was supposed to be
> pretty universal.
> 
> Would you be thinking that a string match would throw an exception on
> failure?

Sorry, that was just my facetious off-the-cuff reaction :)  Obviously,
exceptions are more awkward to deal with than just checking for nil.  What I
meant was that all the nifty functionality FailureClass brings is already
implemented in exceptions (don't even have to write kind_of?).  So I'd say: if
you need to indicate a complex kind of failure (that FailureClass would be
useful for---one that can carry extra info like errno, friendly msg for user,
debugging info, etc.) then throw an exception.  When you want all that fancy
stuff, it's hard to avoid the extra verbiage anyway.  But when you want to
indicate simple failure for a "do one thing" method that is meant to be used
in expressions, use nil (so long as nil is obviously not in the set of valid
returns (which is why I'd expect an invalid hash lookup to throw an exception
rather than return nil, since a hash should be able to store 'nil's, but maybe
I'm too used to python)).

Obviously it's not a clear distinction, and you can see where python struggles
with such things when it provides two functions like string.index and
string.find that do the same thing except one raises and exception and the
other returns -1 on failure.  There's duplicated functionality here, but we're
unlikely to get rid of that unless we design a new language where control
structures like if and while are designed to handle exceptions:

while line = f.readline
    if line =~ /^h/ then
        p 'yay'
    except MatchError then
        p 'bad string'
    except RECompileError then
        p '/^h/ is not a valid re?'
    end
except EOFError
    f.close
end

I need to go write something interesting in icon :)



While I'm on the subject of hashes, could anyone tell me why:

% cat >hash.rb
d = {'a' => 1, 'b' => 2}
p d
d[10] = nil
p d
% ruby hash.rb
{"a"=>1, "b"=>2}
{"a"=>1}
%

What happened to d['b'] ?