RAII / handling failures during destruction - advice required

Discussion in 'C++' started by MikeB, Oct 24, 2004.

  1. MikeB

    MikeB Guest

    Hi,



    Recently I was asked to look at some code where RAII is used to ensure
    automatic cleanup of a resource. Unfortunately, cleaning up the resource
    requires that the destructor make a call to an API which can (albeit under
    dire circumstances) fail. As it stands, in the presence of a failed call to
    the API, the destructor does nothing more than record the event in the
    system log.



    I'm uncomfortable with the fact that code further up the stack is unaware of
    the failure but I'm also aware of the issues surrounding the throwing /
    propagation of exceptions from destructors.



    In view of this, I'm left wondering whether or not RAII is acceptable as a
    means of managing this type of resource.



    I'd appreciate others views on this.



    Thanks in anticipation.

    MikeB
    MikeB, Oct 24, 2004
    #1
    1. Advertising

  2. * MikeB:
    >
    > Recently I was asked to look at some code where RAII is used to ensure
    > automatic cleanup of a resource. Unfortunately, cleaning up the resource
    > requires that the destructor make a call to an API which can (albeit under
    > dire circumstances) fail. As it stands, in the presence of a failed call to
    > the API, the destructor does nothing more than record the event in the
    > system log.
    >
    > I'm uncomfortable with the fact that code further up the stack is unaware of
    > the failure but I'm also aware of the issues surrounding the throwing /
    > propagation of exceptions from destructors.
    >
    > In view of this, I'm left wondering whether or not RAII is acceptable as a
    > means of managing this type of resource.


    Do whatever is appropriate.

    I.e., does the failed API call have an effect, and if so at what level
    (thread, process, system, network), and who (computerwise, userwise)
    should do something about that, if anything?

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Oct 24, 2004
    #2
    1. Advertising

  3. MikeB

    MikeB Guest

    "Alf P. Steinbach" <> wrote in message
    news:...
    > Do whatever is appropriate.
    >
    > I.e., does the failed API call have an effect, and if so at what level
    > (thread, process, system, network), and who (computerwise, userwise)
    > should do something about that, if anything?


    I'm not sure that the details are that relevant, but for the sake of
    completeness, the failure of the API indicates that a lock which was at some
    point acquired could not, for whatever reason, be released. Furthermore, the
    class which manages the lock is a component from a 'generic' library, so in
    the great tradition of error handling, I'm not convinced that it can know
    how to 'do whatever is appropriate'.



    I'd appreciate your input on how to 'do whatever is appropriate' in a
    flexible manner.



    Rgds,

    MikeB
    MikeB, Oct 24, 2004
    #3
  4. * MikeB:
    >
    > "Alf P. Steinbach" <> wrote in message
    > news:...
    > > Do whatever is appropriate.
    > >
    > > I.e., does the failed API call have an effect, and if so at what level
    > > (thread, process, system, network), and who (computerwise, userwise)
    > > should do something about that, if anything?

    >
    > I'm not sure that the details are that relevant, but for the sake of
    > completeness, the failure of the API indicates that a lock which was at some
    > point acquired could not, for whatever reason, be released. Furthermore, the
    > class which manages the lock is a component from a 'generic' library, so in
    > the great tradition of error handling, I'm not convinced that it can know
    > how to 'do whatever is appropriate'.
    >
    > I'd appreciate your input on how to 'do whatever is appropriate' in a
    > flexible manner.


    If it doesn't have any measurable effect, just log it (from the program)
    and report it in whatever error reporting system is used (e.g. Bugzilla).

    Otherwise if it can be easily dealt with at some level (e.g. terminating a
    tread, process, system), do that also.

    Otherwise leave it to the user to decide.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Oct 24, 2004
    #4
  5. On Sun, 24 Oct 2004 22:33:16 +0000, Alf P. Steinbach wrote:

    > * MikeB:
    >>
    >> "Alf P. Steinbach" <> wrote in message
    >> news:...
    >> > Do whatever is appropriate.
    >> >
    >> > I.e., does the failed API call have an effect, and if so at what level
    >> > (thread, process, system, network), and who (computerwise, userwise)
    >> > should do something about that, if anything?

    >>
    >> I'm not sure that the details are that relevant, but for the sake of
    >> completeness, the failure of the API indicates that a lock which was at some
    >> point acquired could not, for whatever reason, be released. Furthermore, the
    >> class which manages the lock is a component from a 'generic' library, so in
    >> the great tradition of error handling, I'm not convinced that it can know
    >> how to 'do whatever is appropriate'.
    >>
    >> I'd appreciate your input on how to 'do whatever is appropriate' in a
    >> flexible manner.

    >
    > If it doesn't have any measurable effect, just log it (from the program)
    > and report it in whatever error reporting system is used (e.g. Bugzilla).
    >
    > Otherwise if it can be easily dealt with at some level (e.g. terminating a
    > tread, process, system), do that also.
    >
    > Otherwise leave it to the user to decide.


    To add to Alf Steinbach's good advice, I'd be inclined to test that the
    lock is actually released using an assertion. The general case is that,
    if you can acquire the lock, you should always be able to release it, and
    if you can't there's likely a problem somewhere more fundamental than your
    code.

    So, if you're working with a "debug" version with assertions enabled,
    it'll let you know when it happens, and at runtime a "mostly useless"
    check goes away.

    I'd be inclined to implement that in the header file, so that clients of
    your library can enable and disable assertions themselves, even if the
    rest of the library implementation is in the actual sources.

    Owen

    --
    Some say the Wired doesn't have political borders like the real world,
    but there are far too many nonsense-spouting anarchists or idiots who
    think that pranks are a revolution.
    Owen Jacobson, Oct 26, 2004
    #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. ian douglas
    Replies:
    0
    Views:
    1,806
    ian douglas
    Aug 19, 2003
  2. Replies:
    9
    Views:
    655
    Carl Friedrich Bolz
    Feb 5, 2006
  3. Johannes Schaub (litb)

    Re: Why is RAII called RAII?

    Johannes Schaub (litb), Sep 12, 2010, in forum: C++
    Replies:
    2
    Views:
    387
    James Kanze
    Sep 18, 2010
  4. cpp4ever

    Re: Why is RAII called RAII?

    cpp4ever, Sep 12, 2010, in forum: C++
    Replies:
    1
    Views:
    394
    BGB / cr88192
    Sep 13, 2010
  5. Goran Pusic

    Re: Why is RAII called RAII?

    Goran Pusic, Sep 13, 2010, in forum: C++
    Replies:
    11
    Views:
    535
    ptyxs
    Sep 16, 2010
Loading...

Share This Page