error handling: two flavors?

G

Grary Stimon

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
 
R

Robert Klemme

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
 
G

Grary Stimon

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
http://ruby-doc.org/docs/ProgrammingRuby/html/tut_...) that this had a
special approach associated with it (one different, say, from Java).

Thanks,

Grar
 
R

Robert Klemme

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

2. 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
http://ruby-doc.org/docs/ProgrammingRuby/html/tut_...) 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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top