{
   File a,b;
   // ... - may throw
   b.close(); // may throw
   a.close(); // may throw
}

{
   File a,b;
   scope(success)
   {
      b.close(); // may throw
      a.close(); // may throw
   };
   // ... - may throw   
}

{
   File a,b;
   // ... - may throw   
}

}

http://ju.outofmemory.cn/entry/16293
Toward an Answer

So there you have it. The reason we can’t have throwing destructors is that nobody worked out how to deal with multiple exceptions wanting to propagate through the same set of stack frames. Considering the fact that the program knows how to unwind from here, even if it doesn’t know exactly what to propagate, and the fact that it’s so easy to throw from a destructor by mistake, we think termination is a bit draconian.

Frankly, we don’t think it’s so hard to nail down the final details of how this should work. For example, it might be reasonable to simply drop the second exception on the floor and propagate the original one. Before you freak out, consider this: the second exception doesn’t change the unwinding process in any way, at least, not until the exception is caught, and the original failure is still the root cause of the current unwind. The program or the user can likely deal just as well with that root cause without knowing anything about the second exception.

This being C++, we expect someone to want more control over that second exception, so in our next installment, we’ll consider some alternatives. For now, we leave you with the suggestion that maybe destructors that throw are not truly Evil™, but just misunderstood.

EP>{
EP>   File a,b;
EP>   // ... - may throw   
EP>}
EP>

class File 
{
public:
 ~File()
 {
  // старый добрый деструктор без исключений
 }

 ~~File()
 {
  // а тут можно кинуть если надо
 }
}

class A
{
//.....
    ~A() {
         if(!m_file.save())
             LASY_THROW(FileSaveException());
     }
};

///...........
{
    A a;
    // do some stuff
    // ....
}
RETHROW();