From: Nick Green <cruzmail.ngreen@...>
Date: 2009-09-14T09:52:08+09:00
Subject: Re: Type checking function parameters

Hahah, yes I pulled the example completely out of my... well out of thin 
air;p  I wasn't thinking how one would implement the whole, just trying 
to get a feel for error handling.  However, your in depth critique of my 
culinary function is appreciated, as is your rescue example.  I 
understand that were it in a bigger program the failsafes would be 
elsewhere, but I do think there are cases where, so to speak, "the show 
must go on" and I was wondering how best to go about that in ruby.  This 
thread has more-than-answered my question :)

Also, great slides on the link in your sig.

p.s. I like camel case :'( and i do indeed define logMessage in most of 
my code;P

Eleanor McHugh wrote:
> 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

-- 
Posted via http://www.ruby-forum.com/.