>>>>> "Tobias" == Tobias DiPasquale <anany / ece.villanova.edu> writes:

    Tobias> I agree totally. This is absolutely essential to building
    Tobias> fault-tolerant systems in Ruby. If I don't know what
    Tobias> exceptions a method will throw, or even if it throws
    Tobias> exceptions, how can I know how to handle them correctly?

I have a different take on exceptions.  I believe exceptions should be
thrown when the called method has failed, where failure is defined as
unable to met its contract (either formally defined via Design by
Contract or informally defined some other way).  Trying to communicate
exactly how a method fails through exceptions unnecessarily couples
the client code to the supplier code.  

For example, suppose we have method do_something() that can throw an
OutOfRangeError or a InverseNotFoundError exceptions (just examples).
We carefully handle both of these errors in our client code.  Then our
code is given an object that implements do_something() via a network
proxy object.  All of a sudden we could possibly get a NetworkError
exception as well.  If our code doesn't expect a NetworkError, then we 
have problems.

We should expect exceptions to happen and handle them, but trying to
anticipating all the failure modes and responding differently in each
case is a dangerous path.   I believe that treating all exceptions as
failures (without distiguishing different failure modes) is a better
way to go.

Of course, this is just my take on exceptions.  I know others
disagree.

-- 
-- Jim Weirich     jweirich / one.net    http://w3.one.net/~jweirich
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct, 
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)