[petsc-dev] Remove calls to XXXReset() in XXXDestroy()

[Barry Smith]

On May 13, 2011, at 10:26 AM, Jed Brown wrote:

> On Fri, May 13, 2011 at 17:03, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > BTW, Writing a REALLY good destructor in C++ is a
> > pain. What's happens if an exception is thrown in the middle of object
> > destruction and you still have things to delete[]?
> 
>   Then I would argue that something is wrong with C++ in this regard.
> 
> Perhaps, but the larger problem is independent of language and independent of parallelism. Say you have several lock files open. The locks have to be released in a specific order. When you try to close one, an exception/error is returned. What do you do? If you exit early, then locks remain that will cause problems in the future. If you ignore the error, perhaps something really bad could happen (corruption?). There isn't any general-purpose rule that can be applied when there are errors in destructors. PETSc has chosen that no integrity is guaranteed if a function returns an error. If you want to maintain integrity, then you basically have no choice but to say that exceptions in destructors are BAD. You can do this by having the caller not check error codes (or try: destroy(); except: pass) or by preventing destructors from returning errors.
> 
> It's a similar issue to why PETSc does not check for errors in its own error handlers.

   I agree it is an exceedingly hard problem to solve in general; I am not claiming I know how to solve it or even what a good solution is. My comment is only that they punted on problem (just like PETSc punts on the problem)