🚀 go-pugleaf

Although the language doesn't mandate this, it's a good idea to obey the 
rule: never, _never_, NEVER throw an exception from within a destructor. 
If there's one operation that should be guaranteed to "work", it's 
destroying an object. Remember that destructors are automatically called 
during stack unwinding when an exception is thrown. If such a destructor 
should throw another exception, what should happen? In fact, the 
standard states that in this situation, terminate() will be called, and 
terminate() is only one notch less violent than abort().

You can, of course, use exceptions _within_ a destructor, as long as you 
handle them all. Just don't let them leak out, or you'll be hosed.

If an error might occur during destruction of an object, try to design 
in a separate termination function that can be called first. For 
instance, say you've got an object that represents an open file, and 
destroying the object is supposed to commit any buffers and close the 
file. What happens if a disk write occurs during the buffer writing?

The best approach is to design the destructor so that the error is 
swallowed, to avoid violating the above rule. If you need to see the 
error, supply a commit() member that can be called before destroying the 
object, that will detect any disk errors and leave the file object in a 
state that can be destroyed without causing any errors.

-- 

Ciao,
Paul D. DeRocco
---
[ To submit articles: Try just posting with your newsreader.  If that fails,
                      use mailto:std-c++@ncar.ucar.edu
  FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std.c++-request@ncar.ucar.edu 
]