Prev: Template is missing statement
Next: The price of a modern list architecture?
From: Carl Jenkins on 18 Jul 2010 15:56
I am working to learning Ruby and have a bit of a question regarding
program structure.

In Java we typically checked (at the beginning of a method) for null and
that the parameters being passed in are of a certain value.

Maybe I am still (very) new to this world but, are null checks done a
lot in the real world with Ruby?

For example, I have seen a lot of code doing something like

if(obj == null){
log.error(...);
throw new SomeException(errMsg);
}

if(obj2 == null){
log.error(...);
throw new SomeException(errMsg);
}

Does this happen in Ruby programs as well?
--
Posted via http://www.ruby-forum.com/.

From: Robert Klemme on 18 Jul 2010 16:52
On 18.07.2010 21:56, Carl Jenkins wrote:
> I am working to learning Ruby and have a bit of a question regarding
> program structure.
>
> In Java we typically checked (at the beginning of a method) for null and
> that the parameters being passed in are of a certain value.

That does make sense although often null checks are superfluous because
the JVM will do it for you once you use a null reference. You only need
the explicit null check if you want to throw another exception or check
the argument before beginning of the work (i.e. modifying some state).

> Maybe I am still (very) new to this world but, are null checks done a
> lot in the real world with Ruby?

Probably less often than in Java. Some of them are actually hidden,
e.g. in the typical idiom

h = {}
....
h[key] ||= []

the ||= operator in this case does an implicit check for "nil" (or "false").

> For example, I have seen a lot of code doing something like
>
> if(obj == null){
> log.error(...);
> throw new SomeException(errMsg);
> }
>
> if(obj2 == null){
> log.error(...);
> throw new SomeException(errMsg);
> }

This is bad code IMHO. Reason: either you handle the error by logging
it or you cannot continue at this place and throw an exception. If you
do both someone up the call chain might catch the exception and also log
the error because that is the only resolution he can do. Now you got
two log statements for the single error. Even worse, the catcher of the
exception may handle it in a way that there is no overall error. Now
you end up with an error log statement which is not an error. That
costs IO and can send someone looking for the complete wrong cause when
looking for the cause of a program's misbehavior.

> Does this happen in Ruby programs as well?

Most of the time we use what we are passed and simply let the
interpreter throw an exception if it does not meet our expectations
(i.e. understand the messages we send to it). Note that in Ruby you can
actually invoke methods on nil although not many do actually make sense
(#to_s is one of them).

See also: Duck typing.

Kind regards

robert


PS: Note also a subtle difference between Java and Ruby: Java's null is
actually nothing while Ruby's nil is an instance:

irb(main):001:0> nil.object_id
=> 4
irb(main):002:0> nil.object_id
=> 4
irb(main):003:0> nil.nil?
=> true
irb(main):004:0> nil.to_s
=> ""
irb(main):005:0> nil
=> nil
irb(main):006:0> puts nil.inspect
nil
=> nil
irb(main):007:0>


--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
 | 
Pages: 1
Prev: Template is missing statement
Next: The price of a modern list architecture?