Error handling: two flavors?

Ruby
1

Hi,

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!

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

Grar

2

Stop

3

On 10/26/2010 9:54 AM, Grary S. wrote:

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!

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

It sounds like you’re remembering reading about exceptions, catch, and
throw:

http://ruby-doc.org/docs/ProgrammingRuby/html/tut_exceptions.html

In your case, I think you want to use exceptions. I know I haven’t seen
throw and catch used very often, especially not for the kind of error
processing you’re describing.

-Jeremy

4

On 26.10.2010 16:54, Grary S. wrote:

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’

Kind regards

robert

5

Robert,

Yes, my method would be like find, except I envisioned using a special
class of error to account for the case that #find cannot get the
‘finder’, which, itself, could report nil in the case that the object
sought did not exist. my thinking was that the finder might well not be
available, so that case was not truly ‘exceptional’, whereas if the
finder were available, but maybe improperly initialized, then that would
be exceptional, etc. my special class of error would save me from
multiple return values, e.g., [nil, nil].

I guess I can capture my meaning by defining a error specific to my
concern.

I was just puzzled, because I thought I read (not at
Programming Ruby: The Pragmatic Programmer's Guide…) that this had a
special approach associated with it (one different, say, from Java).

Thanks,

Grar

6

On Tue, Oct 26, 2010 at 6:48 PM, Grary S. [email protected]
wrote:

Yes, my method would be like find, except I envisioned using a special
class of error to account for the case that #find cannot get the
‘finder’, which, itself, could report nil in the case that the object
sought did not exist. my thinking was that the finder might well not be
available, so that case was not truly ‘exceptional’,

On first sight I would consider this exceptional. Your description
sounds as if this is a two step approach:

fnd = obtain_finder
result = fnd.find_all

Now there seem to be mainly two reasonable ways to do this:

  1. one method, with exception

1a)

may return nil if there is no finder

def obtain_finder
…
end

def find_something
fnd = obtain_finder or raise “Cannot obtain finder!”
return fnd.find_all
end

or

1b)

def obtain_finder
raise “Cannot obtain finder!” if some_condition
return the_finder
end

def find_something
return obtain_finder.find_all
end

Use

begin
x.find_something
rescue => e
$stderr.puts “Sorry, cannot search because of #{e.message}.”
end

  1. two methods

may return nil if there is no finder

def obtain_finder
…
end

class Finder
def find_all
…
end
end

Use:

f = obtain_finder
if f
f.find_all
else
$stderr.puts “Sorry, cannot search.”

or other reaction

end

My preference would be 1b because in this case the exception raised
from obtain_finder can include the reason for the error.

whereas if the
finder were available, but maybe improperly initialized, then that would
be exceptional, etc. my special class of error would save me from
multiple return values, e.g., [nil, nil].

I guess I can capture my meaning by defining a error specific to my
concern.

If you mean “defining an exception” then yes, probably.

I was just puzzled, because I thought I read (not at
Programming Ruby: The Pragmatic Programmer's Guide…) that this had a
special approach associated with it (one different, say, from Java).

I have no idea what you are referring to. Of course, Ruby != Java,
but the main difference with regard to error handling is the fact that
Ruby does not have checked exceptions - while it has the distinction
between StandardError and not. And exception hierarchies are built
differently of course.

Cheers

robert