From: Robert Klemme <shortcutter@...>
Date: 2009-09-14T16:43:49+09:00
Subject: Re: Type checking function parameters

2009/9/10 Eleanor McHugh <eleanor@games-with-brains.com>:

> class ButterQueue
>  def initialize
>    @queue = []
>  end
>
>  def butter_up
>    begin
>      @queue.shift.but_butter_on
>    rescue Exception=> e
>      log_message e
>      raise
>    end
>  end
> end
>
> I've rewritten the error handling so that it creates a message in the log
> (assuming log_message to be defined somewhere in scope) and then re-raised
> it so that the calling code can decide how to handle it. This allows an
> error to be handled separately from a nil value return as the latter may
> have some specific semantic meaning.

I find it debatable whether this pattern does make sense: if the
calling code can handle the exception in a meaningful way, there is no
point in logging it, because that would attract suspicion where it is
not in order.  I would say that logging is a form of handling, i.e. if
the calling code does not know what to do about it, it can still log
the error.  If you log it in the source location then this could be
viewed as violating the principle of "let the calling code decide how
to handle the exception".

One more reason against this pattern: if this is done on multiple
levels you'll get the exact same error multiple times in the log which
does not really help clear things up.

> I hope this all makes sense, but if not I'd be happy to discuss it further
> off-list.

Please let's keep it on list.  We would miss your mellow home brew comments. :-)

Kind regards

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/