> Am I wrong or is there a fundmanental flaw in the language when it comes
to
> handling exceptions inside a destructor. The experts provide sufficient
> reason why you never should but how do you then inform the outside world
> that a destructor failed?

A destructor should not fail. If you thow an exception in a destructor, in
the process of the stack unwinding to look for an appropriate catch handler,
what should destructors of local objects do if they fail? You are already in
a pending exception, and throwing a 2nd, 3rd exception does not help.

The only clean solution to this is _NEVER_ throw from a destructor.

> I can't see any *clean* way of doing it.

There is one way. An example:

I have a class that manages a file resource. It is perfectly possible that
fileclose() for the file might fail. So I provide a member function called
Close() which in turn calls fileclose() (and other resources) and leaves the
object knowing that it is in a "shutdown" state. If Close() succeeds then
the destructor won't have to do much. If Close() fails, then you can report
this or throw an exception.

But what happens if Close() is not called and the destructor kicks in, calls
fileclose() and it fails? In that case there is nothing you can do. But if
you had called Close() beforehand, you can do something.

Stephen Howe






      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]

On 2003-02-14 10:21, Stephen Howe <SPAMstephen.howeGUARD@tnsofres.com> wrote:
>> Am I wrong or is there a fundmanental flaw in the language when it
>> comes to handling exceptions inside a destructor. The experts
>> provide sufficient reason why you never should but how do you then
>> inform the outside world that a destructor failed?
[...]
>> I can't see any *clean* way of doing it.
>
> There is one way. An example:
>
> I have a class that manages a file resource. It is perfectly possible that
> fileclose() for the file might fail. So I provide a member function called
> Close() which in turn calls fileclose() (and other resources) and leaves the
> object knowing that it is in a "shutdown" state. If Close() succeeds then
> the destructor won't have to do much. If Close() fails, then you can report
> this or throw an exception.

That doesn't help. Consider:

   void f(some params)
   {
      resource_manager my_object(params);
      try
      {
         do_something_with(my_object);   // may throw, fine
      }
      catch (std::exception const & A)
      {
         try
         {
            my_object.close();  // may throw, but...
         }
         catch (std::exception const & B)
         {
            // ...now what???    (C)
         }
         throw;
      }
      my_object.close();  // may throw, fine
   }

What code do you suggest at (C) that constitutes a "clean way" to
handle that situation? How do you decide whether exception A is more
important than exception B? Or whether both are unrelated and of equal
importance? Maybe f()'s caller knows better, or someone else up the
call chain? Isn't that a specific purpose of exceptions, to let
someplace higher up decide what to do about some exceptional
situation?

Note that you have to use a construction like the above for each and
every use of resource_manager. Unless you decide to silently ignore
certain errors, that is.

-- Niklas Matthies
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]