<div class="gmail_quote">On Fri, May 13, 2011 at 17:03, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> BTW, Writing a REALLY good destructor in C++ is a<br>
> pain. What's happens if an exception is thrown in the middle of object<br>
> destruction and you still have things to delete[]?<br>
<br>
</div>   Then I would argue that something is wrong with C++ in this regard.</blockquote></div><br><div>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.</div>
<div><br></div><div>It's a similar issue to why PETSc does not check for errors in its own error handlers.</div>