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

On Tue, Oct 26, 2010 at 6:48 PM, Grary Stimon <grary.stimon@gmail.com> 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

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

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