error handling: two flavors?

Discussion in 'Ruby' started by Grary Stimon, Oct 26, 2010.

  1. Grary Stimon

    Grary Stimon Guest

    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/.
     
    Grary Stimon, Oct 26, 2010
    #1
    1. Advertising

  2. Grary Stimon

    Cliff Phiri Guest

    [Note: parts of this message were removed to make it a legal post.]

    Stop
    On Tue, Oct 26, 2010 at 7: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?
    >
    > Grar
    >
    > --
    > Posted via http://www.ruby-forum.com/.
    >
    >
     
    Cliff Phiri, Oct 26, 2010
    #2
    1. Advertising

  3. 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/
     
    Robert Klemme, Oct 26, 2010
    #3
  4. Grary Stimon

    Grary Stimon Guest

    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/.
     
    Grary Stimon, Oct 26, 2010
    #4
  5. On Tue, Oct 26, 2010 at 6:48 PM, Grary Stimon <> 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/
     
    Robert Klemme, Oct 27, 2010
    #5
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andrew Thompson

    Detecting Unix flavors

    Andrew Thompson, Sep 5, 2004, in forum: Java
    Replies:
    21
    Views:
    1,745
  2. Replies:
    5
    Views:
    1,944
    Andrew Thompson
    Jan 12, 2005
  3. Jeff Thies

    OT: CSV flavors

    Jeff Thies, Jul 21, 2004, in forum: HTML
    Replies:
    2
    Views:
    440
    Jeff Thies
    Jul 22, 2004
  4. kbutterly
    Replies:
    3
    Views:
    404
    kbutterly
    Jan 30, 2007
  5. Michael Olea

    What to name container "flavors"?

    Michael Olea, Jun 30, 2005, in forum: C++
    Replies:
    2
    Views:
    321
    Michael Olea
    Jul 1, 2005
Loading...

Share This Page