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




.

Relevant Pages