What risk of undefined behavior if destructor must throw?

Forgive me. I know this has probably been hashed out several times over
the
last 10 years, but I wasn't paying attention then.

I understand that a destructor that throws is "bad".
I also understand that if a destructor throws while unwinding, terminate()
is called.

Given that I have a destructor that might throw, what "bad" things might
happen when it does?

The following is a simple, pseudo-real-life example. Please focus on the
throwing destructor aspect and not the (more interesting?)
multithreaded/Windows aspects.

I can't think of a reason why ReleaseMutex would throw since I'm using
RAII,
so if the destructors is called, I can assume that the calling thread owns
the mutex and the handle is valid. But I don't _know_ that ReleaseMutex
won't throw for some other reason.

What "bad" things could happen by a throwing destructor in this example?

class MutexGuard {
   HANDLE handle;

public:
     MutexGuard(HANDLE h) : handle(h) {
         if (!WIN32_API::AcquireMutex(handle)) // Not a real WIN32 API
function -- just pretend.
             throw Win32Error(GetLastError());
         // Ok. 'handle' is valid, I own the mutex.
     } // ctor

     ~MutexGuard() {
         if (WIN32_API::ReleaseMutex(handle))
             return;
         unsigned long error = WIN32_API::GetLastError();
         Log << "Oh no!! Its almost inconcievable, but ::ReleaseMutex
failed
with error code: " << error << endl;
         throw Win32Error(error); // Hope for the best.
     } // dtor
}; // MutexGuard

terry

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]