Hi John,

My last post seems not appear yet -- usually it appears very fast. So I
repeat myself briefly:

I want my program to be robust. I don't want to check it after my
program is running in production environment. I want it to be
self-curable, i.e., tolerate these errors.

Is it possible to "overload" the Nil class so that it is polymophic? for
example,

if the method upcase is called, nil act like string, if the expression
a = 2 + nil is executed, nil act like zero? That will be fantastic.

Thanks for your help.

Shannon


On Wed, 16 Jul 2003 01:43:45 +0900
"John W. Long" <ng / johnwlong.com> wrote:

> Actually I consider it better not to check the type. You should get used to
> looking at the stack trace to see what is wrong.
> 
> Generally you'll get some kind of method missing error. Then you puts the
> type of the object being passed in, run your tests again, and check the
> type.
> 
> I think about it this way: if the object passed in implements the correct
> interface then it should be allowed to be passed in, regardless of whether
> it is an instance_of? or kind_of? a certain object.
> 
> If you need to prevent a certain kind of class from being passed in (such as
> the Nil class in your example) check for it at the beginning of your method
> like so:
> 
> raise "cannot accept nil argument" if object.nil?
> 
> I would consider it preferable to exclude based on type rather than include
> based on type.
> 
> --
> John Long
> 
> 
> 
> > -----Original Message-----
> > From: Hal E. Fulton [mailto:hal9000 / hypermetrics.com]
> > Sent: Tuesday, July 15, 2003 11:21 AM
> > To: ruby-talk ML
> > Subject: Re: How to reduce Ruby runtime error?
> >
> >
> > ----- Original Message -----
> > From: "Xiangrong Fang" <xrfang / hotmail.com>
> > To: "ruby-talk ML" <ruby-talk / ruby-lang.org>
> > Sent: Tuesday, July 15, 2003 11:05 AM
> > Subject: How to reduce Ruby runtime error?
> >
> >
> > > Hi my friends,
> > >
> > > I am thinking of how can I reduce Ruby runtime error. Not like
> > > languages such as C or Pascal, Ruby is typeless. This is a
> > good thing,
> > > especially in design time. However, I found that my
> > application is not
> > > stable due to this feature.
> > >
> > > For example, a routine is expecting a string, and this
> > string turned out
> > > to be nil at runtime, an error occurred. In Delphi, for
> > example, it is
> > > impossible that a string becomes a nil, it will be an empty string.
> > >
> > > How can I better utilize Ruby's typeless feature yet avoid
> > such anonying
> > > runtime problem?
> >
> > You can always check types explicitly if you
> > really want to:
> >
> >     raise "Expecting an array" if not x.is_a? Array
> >
> > Or you could test for nil:
> >
> >     raise "Argument was nil" if x.nil?
> >
> > You can test for methods available ("duck typing")
> > rather than actual class:
> >
> >     raise "Object has no 'push' method" if not x.respond_to? :push
> >
> > You can check for the "magic" conversion methods such as
> > to_str and to_ary:
> >
> >     if not x.is_a? String
> >       x = x.to_str if x.respond_to? :to_str
> >     else
> >       raise "Wanted a string"
> >     end
> >
> > Not recommended: You could convert a nil value on entry
> > into the method:
> >
> >     x = [] if x.nil?
> >
> > Not recommended: You could modify the NilClass so that a
> > nil value acted the way you want:
> >
> >     class NilClass
> >       def +(value)
> >         value       # nil + x always equals x
> >       end
> >     end
> >
> > I'm sure there are other ways.
> >
> > Hal
> >
> > --
> > Hal Fulton
> > hal9000 / hypermetrics.com
> >
> >
> >
> >
> >
> 

-- 
Xiangrong Fang <xrfang / hotmail.com>