From: Robert Klemme <shortcutter@...>
Date: 2010-10-27T00:50:12+09:00
Subject: Re: error handling: two flavors?

On 26.10.2010 16:54, Grary Stimon wrote:
> I recall reading somewhere (can't remember where) that there are two
> flavors of error handling available in ruby: 1) for truly unexpected
> contingencies, and 2) for other infrequent but expected contingencies.
>
> So, I expect a method to return a value, including nil. But
> if the method cannot return a value, including nil, i want it to return
> a result along the lines of 2), above. it's not that i didn't anticipate
> the case that my method might not be able to return a value, including
> nil, rather, if it can't then i need to know based on some indicator
> other
> than nil, which is a meaningful value for my method!

It is generally not a good idea to use return values for error reporting 
in a language that supports Exceptions.  Numerous articles have been 
written on this on the web.  So for error reporting you better use 
exceptions.

Returning nil from a method like Enumerable#find is a different story 
because not finding anything is a completely expected outcome of a 
search operation.

> can anyone refresh me on whether there are these two flavors of error
> handling in ruby?

Do you mean the distinction between exceptions inheriting StandardError 
and others?

irb(main):001:0> begin
irb(main):002:1* Object.new.foo
irb(main):003:1> rescue => e
irb(main):004:1> puts "Caught #{e}"
irb(main):005:1> end
Caught undefined method `foo' for #<Object:0x1055a754>
=> nil
irb(main):006:0> begin
irb(main):007:1* raise ScriptError, "won't be caught"
irb(main):008:1> rescue => e
irb(main):009:1> puts "Caught #{e}"
irb(main):010:1> end
ScriptError: won't be caught
         from (irb):7
         from /usr/local/bin/irb19:12:in `<main>'

Kind regards

	robert

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