title: RAII vs. exceptions
body: <p>The more we use RAII in C++, the more we find ourselves with destructors that do non-trivial deallocation. Now, deallocation (finalization, however you want to call it) can fail, in which case exceptions are really the only way to let anybody upstairs know of our deallocation problem. But then again, throwing-destructors are a bad idea because of the possibility of exceptions being thrown during stack unwinding. <code>std::uncaught_exception()</code> lets you know when that happens, but not much more, so aside from letting you log a message before termination there's not much you can do, unless you're willing to leave your program in an undefined state, where some stuff is deallocated/finalized and some not.</p>
  
  <p>One approach is to have no-throw destructors. But in many cases that just hides a real error. Our destructor might, for example, be closing some RAII-managed DB connections as a result of some exception being thrown, and those DB connections might fail to close. This doesn't necessarily mean we're ok with the program terminating at this point. On the other hand, logging and tracing these errors isn't really a solution for every case; otherwise we would have had no need for exceptions to begin with. 
  With no-throw destructors we also find ourselves having to create "reset()" functions that are supposed to be called before destruction - but that just defeats the whole purpose of RAII.</p>
  
  <p>Another approach is just to <a href="http://www.kolpackov.net/projects/c++/eh/dtor-1.xhtml" rel="noreferrer">let the program terminate</a>, as it's the most predictable thing you can do.</p>
  
  <p>Some people suggest chaining exceptions, so that more than one error can be handled at a time. But I honestly never actually seen that done in C++ and I've no idea how to implement such a thing.</p>
  
  <p>So it's either RAII or exceptions. Isn't it? I'm leaning toward no-throw destructors; mainly because it keeps things simple(r). But I really hope there's a better solution, because, as I said, the more we use RAII, the more we find ourselves using dtors that do non-trivial things.</p>
  
  <p><strong>Appendix</strong></p>
  
  <p>I'm adding links to interesting on-topic articles and discussions I've found:</p>
  
  <ul>
  <li><a href="http://www.kolpackov.net/projects/c++/eh/dtor-1.xhtml" rel="noreferrer">Throwing Destructors</a></li>
  <li>StackOverflow discussion on the <a href="https://stackoverflow.com/questions/164372/is-there-a-good-way-around-the-problems-of-structured-exception-handling-try-ex">problems with SEH</a></li>
  <li>StackOverflow discussion on <a href="https://stackoverflow.com/questions/130117/throwing-exceptions-out-of-a-destructor#130123">throwing-destructors</a> (thanks, Martin York)</li>
  <li><a href="http://www.joelonsoftware.com/items/2003/10/13.html" rel="noreferrer">Joel on Exceptions</a></li>
  <li><a href="http://blogs.msdn.com/larryosterman/archive/2004/09/10/228068.aspx" rel="noreferrer">SEH Considered Harmful</a> </li>
  <li><a href="http://bartdesmet.net/blogs/bart/archive/2006/04/04/clr-exception-handling-from-a-to-z-everything-you-didn-t-want-to-know-about-try-catch-finally-fault-filter.aspx" rel="noreferrer">CLR Exception Handling</a> which also touches on exception chaining</li>
  <li><a href="http://www.gotw.ca/gotw/047.htm" rel="noreferrer">Herb Sutter on std::uncaught_exception</a> and why it's not as useful as you think</li>
  <li><a href="http://www.cpptalk.net/1-vt12438.html?postdays=0&amp;postorder=asc&amp;start=0" rel="noreferrer">Historical discussion</a> on the matter with interesting participants (long!)</li>
  <li>Stroustrup explaining <a href="http://www.research.att.com/~bs/bs_faq2.html#finally" rel="noreferrer">RAII</a></li>
  <li>Andrei Alexandrescu's <a href="http://www.ddj.com/cpp/184403758" rel="noreferrer">Scope Guard</a></li>
  </ul>