From: gwtmp01@...
Date: 2006-08-07T07:42:44+09:00
Subject: Re: How to react on nil or wrong object-type as parameter


On Aug 6, 2006, at 11:05 AM, Yochen Gutmann wrote:
> this might work in this very simple expample, but what if
>
> class SomeMonsterousClass
>
>    def very_complexe_method a_very_complicated_obejct
>      a_very_complicated_obejct.do_something
>      lots_of_other_operations
>      lots_of_other_operations
>      lots_of_other_operations
>      lots_of_other_operations
>       ...
>    end
> end
>
> So here you cant just convert any given object to
> a_very_complicated_object. By the way your solution would not work  
> with
> nil.

I think Meyers' Design by Contract (DBC) ideas are helpful in talking  
about
this situation.

In DBC terminology, you are asking about how to handle a caller who  
violates
a method's preconditions.  This is a bug in the caller.  A correctly  
written
caller would never violate the precondition.  You basically have two  
choices:

	1) fix the bug by correcting the code in the caller to meet
            the pre-condition of the method
	2) loosen the pre-condition of the method so that the call is valid

Generally I think that 1) is the correct approach and that a good  
testing
framework will help you discover and correct these types of bugs.
Adding lots of checks and raising exceptions in the method itself is too
little, too late. Your testing framework is a better place to spend
the effort of detecting and correcting errors like that.

Sometimes 2) is the better approach.  There are some Ruby idioms that  
are helpful in this situation.  For example, the practice of calling  
to_s on an
argument that will be output in some text format instead of insisting  
that
the *caller* convert the object to a string.  Similarly for to_a,  
to_i, or
to_proc.

Gary Wright