From: Tobias DiPasquale <anany@...>
Date: 2001-12-14T02:09:09+09:00
Subject: [ruby-talk:28428] Re: Documentation of the different Exception types

jweirich@one.net wrote:

> [ruby-talk:28413] Re: Documentation of the different Exception types
> 
>>>>>>"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.


This is an excellent point, and I agree wholeheartedly. However, what I 
intended by my original message was that the base exceptions that the 
methods of the built-in classes and standard libraries by documented, so 
that we can get a basis for which Exceptions to handle. What I mean is, 
given a finite block of methods, do I have to keep putting case 
statements in my rescue clauses to find out which Exception was thrown, 
or can't I just know ahead of time? Obviously there will be more 
Exceptions in cases of complicated code (such as the NetworkError case 
you suggest), but if IO.foreach could never throw a SystemCallError, I 
would like to save myself some lines of code by not checking for it. Do 
you see where I am coming from?


> 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.


This is true, but the problem I am referring to comes about when you 
need to do different things based on the nature of the exception. This 
is where documented exceptions becomes useful. Suppose, for instance, 
that you needed to replace the exception type thrown with a natural 
language string describing the error which goes back out to the user. Am 
I to simply put a giant case statement in my rescue clauses (as I 
alluded to above), or can I get some idea of the Exceptions which 
*might* be thrown ahead of time and save myself some typing?


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

-- 
Tobias DiPasquale
Solaris System Administrator
Electrical and Computer Engineering Dept.
Villanova University
mailto: anany@ece.vill.edu
tel: 610-519-5109