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

[Jed Brown]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110513/9834080a/attachment.html>