From: jweirich@... Date: 2001-12-13T23:32:23+09:00 Subject: [ruby-talk:28413] Re: Documentation of the different Exception types >>>>> "Tobias" == Tobias DiPasquale 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)