Error handling: two flavors?

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

···

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

Stop

···

On Tue, Oct 26, 2010 at 7:54 AM, Grary Stimon <grary.stimon@gmail.com>wrote:

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

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

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

···

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

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?

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

···

On 26.10.2010 16:54, Grary Stimon wrote:

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

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

···

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

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

···

On Tue, Oct 26, 2010 at 6:48 PM, Grary Stimon <grary.stimon@gmail.com> wrote:

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