Best practises for exception handling

Discussion in 'Ruby' started by Alex Dunae, Nov 8, 2007.

  1. Alex Dunae

    Alex Dunae Guest

    I'm write a wrapper for a web service and am wondering about the best
    way to handle exceptions.

    The main method in the wrapper sends either a HEAD or GET request to a
    web server using Net::HTTP.

    Should I catch any exceptions thrown by Net::HTTP and then throw back
    my own exception, or should I leave the exceptions totally un-handled?

    Alex
    Alex Dunae, Nov 8, 2007
    #1
    1. Advertising

  2. Alex Dunae

    Pat Maddox Guest

    On Nov 8, 2007 2:04 PM, Alex Dunae <> wrote:
    > I'm write a wrapper for a web service and am wondering about the best
    > way to handle exceptions.
    >
    > The main method in the wrapper sends either a HEAD or GET request to a
    > web server using Net::HTTP.
    >
    > Should I catch any exceptions thrown by Net::HTTP and then throw back
    > my own exception, or should I leave the exceptions totally un-handled?
    >
    > Alex
    >
    >
    >


    I would raise a new error that's on the same level of abstraction as
    the calling code.

    Pat
    Pat Maddox, Nov 8, 2007
    #2
    1. Advertising

  3. Alex Dunae

    ara.t.howard Guest

    On Nov 8, 2007, at 3:04 PM, Alex Dunae wrote:

    > I'm write a wrapper for a web service and am wondering about the best
    > way to handle exceptions.
    >
    > The main method in the wrapper sends either a HEAD or GET request to a
    > web server using Net::HTTP.
    >
    > Should I catch any exceptions thrown by Net::HTTP and then throw back
    > my own exception, or should I leave the exceptions totally un-handled?



    i generally do one of two things

    a) let the exception pass through. this is ok if, and only if, there
    is nothing reasonable your code could do to retry. if you do retry
    you have you have a configurable numbmer of retries, of course.

    b) wrap the errors. my preferred approach is something like

    module Wrapper
    class Error < ::StandardError
    attr_accessor :exception

    def self.wrapping exception, *a, &b
    e = new *a, &b
    e.exception = exception
    e
    end
    end
    class Specific < Error; end
    class EvenMoreSpecific < Specific; end
    end

    this allows client code respond appropriately to specific errors or
    simply to rescue the entire class of errors your wrapper might throw
    and, when you want to wrap another error you can

    rescue => e
    raise Error.wrapping(e)
    end

    i would say that you have to have a good reason to pick b over a, but
    they do exist.

    cheers.

    a @ http://codeforpeople.com/
    --
    we can deny everything, except that we have the possibility of being
    better. simply reflect on that.
    h.h. the 14th dalai lama
    ara.t.howard, Nov 9, 2007
    #3
  4. ara.t.howard wrote:

    > a) let the exception pass through. this is ok if, and only if, there is
    > nothing reasonable your code could do to retry. if you do retry you
    > have you have a configurable numbmer of retries, of course.
    >
    > b) wrap the errors. my preferred approach is something like


    Another possibility, somewhere between a and b: rescue the exception and
    re-raise, but add some more information to the message. That extra info
    might be, for example, IP address and port during network operations.
    This doesn't change the structure of exception handling, since the
    Exception subclass is the same and it will be handled at the same point,
    eventually, but it can be very useful for logging/debugging and for
    presenting an informative message to the user, if your program is
    interactive.

    --
    vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
    Joel VanderWerf, Nov 9, 2007
    #4
  5. Alex Dunae

    ara.t.howard Guest

    On Nov 8, 2007, at 7:20 PM, Joel VanderWerf wrote:

    > Another possibility, somewhere between a and b: rescue the
    > exception and re-raise, but add some more information to the
    > message. That extra info might be, for example, IP address and port
    > during network operations. This doesn't change the structure of
    > exception handling, since the Exception subclass is the same and it
    > will be handled at the same point, eventually, but it can be very
    > useful for logging/debugging and for presenting an informative
    > message to the user, if your program is interactive.


    good point joel, i recently added this to main:

    ...

    rescue Exception => e
    handle_exception e
    end
    ...

    def handle_exception e
    if e.respond_to?:)error_handler_before)
    fcall(e, :error_handler_before, self)
    end

    if e.respond_to?:)error_handler_instead)
    fcall(e, :error_handler_instead, self)
    else
    if e.respond_to? :status
    exit_status(( e.status ))
    end

    if Softspoken === e or SystemExit === e
    stderr.puts e.message unless(SystemExit === e and
    e.message.to_s == 'exit') ### avoids double message for abort('message')
    else
    fatal{ e }
    end
    end

    if e.respond_to?:)error_handler_after)
    fcall(e, :error_handler_after, self)
    end

    exit_status(( exit_failure )) if exit_status == exit_success
    exit_status(( Integer(exit_status) rescue(exit_status ? 0 : 1) ))
    exit exit_status
    end

    ...

    which basically allows exceptions to be extended with modules or have
    methods defined on them which affect how they are handled. it seems
    like a useful pattern but i've only just started using it.

    cheers.

    a @ http://codeforpeople.com/
    --
    share your knowledge. it's a way to achieve immortality.
    h.h. the 14th dalai lama
    ara.t.howard, Nov 9, 2007
    #5
  6. Alex Dunae

    Alex Dunae Guest

    Note: parts of this message were removed by the gateway to make it a legal Usenet post.

    Joel, A,

    Thank you both for your responses - they made the gap in my knowledge
    quite plain, so I'm off to do some more homework on exceptions.


    Alex

    ara.t.howard wrote:
    >
    > On Nov 8, 2007, at 7:20 PM, Joel VanderWerf wrote:
    >
    >> Another possibility, somewhere between a and b: rescue the exception
    >> and re-raise, but add some more information to the message. That
    >> extra info might be, for example, IP address and port during network
    >> operations. This doesn't change the structure of exception handling,
    >> since the Exception subclass is the same and it will be handled at
    >> the same point, eventually, but it can be very useful for
    >> logging/debugging and for presenting an informative message to the
    >> user, if your program is interactive.

    >
    > good point joel, i recently added this to main:
    >
    > ...
    >
    > rescue Exception => e
    > handle_exception e
    > end
    > ...
    >
    > def handle_exception e
    > if e.respond_to?:)error_handler_before)
    > fcall(e, :error_handler_before, self)
    > end
    >
    > if e.respond_to?:)error_handler_instead)
    > fcall(e, :error_handler_instead, self)
    > else
    > if e.respond_to? :status
    > exit_status(( e.status ))
    > end
    >
    > if Softspoken === e or SystemExit === e
    > stderr.puts e.message unless(SystemExit === e and
    > e.message.to_s == 'exit') ### avoids double message for abort('message')
    > else
    > fatal{ e }
    > end
    > end
    >
    > if e.respond_to?:)error_handler_after)
    > fcall(e, :error_handler_after, self)
    > end
    >
    > exit_status(( exit_failure )) if exit_status == exit_success
    > exit_status(( Integer(exit_status) rescue(exit_status ? 0 : 1) ))
    > exit exit_status
    > end
    >
    > ...
    >
    > which basically allows exceptions to be extended with modules or have
    > methods defined on them which affect how they are handled. it seems
    > like a useful pattern but i've only just started using it.
    >
    > cheers.
    >
    > a @ http://codeforpeople.com/
    > --
    > share your knowledge. it's a way to achieve immortality.
    > h.h. the 14th dalai lama
    >
    >
    >
    >
    Alex Dunae, Nov 9, 2007
    #6
    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. Jon Rea
    Replies:
    14
    Views:
    713
    Gabriel
    Feb 1, 2006
  2. sufferthefools

    Best database practises

    sufferthefools, Jun 20, 2006, in forum: C++
    Replies:
    1
    Views:
    296
    Ian Collins
    Jun 20, 2006
  3. Memfis
    Replies:
    3
    Views:
    406
    mlimber
    Nov 14, 2006
  4. Peter Rilling
    Replies:
    1
    Views:
    378
    PlatinumBay
    Jun 9, 2007
  5. Richard Coltrane

    Site Security - Best Practises

    Richard Coltrane, May 11, 2008, in forum: ASP .Net
    Replies:
    1
    Views:
    228
    Michael Nemtsev [MVP]
    May 11, 2008
Loading...

Share This Page