On 10 Sep 2009, at 04:08, Nick Green wrote:
> def butterUp butter_queue
>  return if butter_queue.empty?
>  begin
>    putButterOn butter_queue.shift
>  rescue err
>    logMsg err
>    butterUp
>  end
> end


A couple of suggestions.

Firstly, camelCase looks really ugly in Ruby programs so I'm going to  
inject the underscores in the following comments.

It would make more sense to populate the butter_queue with objects  
that respond to put_butter_on as these appear to be the message  
recipients. This would also mean that instead of checking on each  
access for an empty queue you could either rescue or propagate the  
NoMethodError when butter_queue.shift produces a nil value.

Taking this idea a step further, butter_up is clearly a method of a  
ButterQueue object, so the whole might be better expressed as:

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 hope this all makes sense, but if not I'd be happy to discuss it  
further off-list.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason