From: Gary Wright <gwtmp01@...>
Date: 2007-03-12T09:14:32+09:00
Subject: Re: string to int: ruby documentation?


On Mar 11, 2007, at 6:39 PM, 7stud 7stud wrote:

> Eden Li wrote:
>> irb(main):036:0> Class.constants.map { |c| eval(c).new rescue
>> nil }.compact.map { |s| Integer(s) rescue $! }.select { |c| c.is_a?
>> (Exception) }.map { |c| c.class }.uniq
>> => [TypeError, ArgumentError, NoMethodError]
>>
>> Looks like it could TypeError and NoMethodError as well...
>
> So the docs don't "document" which exceptions can be thrown by a  
> method?

The documentation isn't perfect.  There is information about  
contributing
to Ruby documentation at www.ruby-doc.org.

It has been my observation that the Ruby style is to avoid the use
of exceptions as part of the expected behavior of a method.  What I mean
is that, in general, if you provide arguments to a method that meet the
method's pre-conditions then you will get back a result with no  
exception
being raised.  If you provide arguments that *don't* meet the
pre-conditions of a method, well then you may or may not get an  
exception
but it is really your problem in either case because you violated the
pre-condition and all bets are off.

Test driven development really puts the burden on the caller to provide
the correct arguments and methods are often written with that explicit
expectation, which tends to reduce the amount of argument checking that
is done in methods.

When exceptions are explicitly part of the behavior of a method then I,
of course, think their use should be documented.

I'd be interested in other perspectives on best practices with respect
to exceptions and argument checking in API/class design.


Gary Wright