On Wed, Oct 19, 2011 at 7:49 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Oct 19, 2011, at 2:45 PM, Matthew Knepley wrote:<br>
<br>
> On Wed, Oct 19, 2011 at 7:39 PM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>> wrote:<br>
> #define CHKERRXX(n)            do {if (PetscUnlikely(n)) {PetscError(PETSC_COMM_SELF,__LINE__,PETSC_FUNCTION_NAME,__FILE__,__SDIR__,n,PETSC_ERROR_IN_CXX,0);}} while(0)<br>
><br>
> Inside PetscError():<br>
><br>
>   if (p == PETSC_ERROR_IN_CXX) {<br>
>     const char *str;<br>
>     if (eh->ctx) {<br>
>       std::ostringstream *msg;<br>
>       msg = (std::ostringstream*) eh->ctx;<br>
>       str = msg->str().c_str();<br>
>     } else {<br>
>       str = "Error detected in C PETSc";<br>
>     }<br>
>     throw PETSc::Exception(str);<br>
>   }<br>
><br>
> This causes SEGV because eh is NULL when propagating an error from C (the caller checks a return code using CHKERRXX). This seems like a logic error, but I don't know what was intended.<br>
><br>
> I changed this to if (eh && eh->ctx) which fixes the SEGV, but I don't know if something else was intended. I only pushed this to petsc-dev, but once we decide on the "right" fix, it should be ported to petsc-3.2.<br>

><br>
> This was intended to get PETSc-like error checking from C++-style functions that throw exceptions. This was mostly for code I<br>
> wrote I think. Your fix is fine.<br>
><br>
> After several years of this, I am now of the opinion that exceptions suck all the way, and I should rewrite all my C++ to use<br>
> return values. The stack does not get wiped out, you can still catch specific errors, and propagate ones you do not catch.<br>
> Does anyone have any serious defense of exceptions?<br>
<br>
</div>    The properly manage the clean up of partially created objects etc don't they, which our C approach cannot handle. Not that I'm advocating for using them or not.</blockquote><div><br></div><div>Hmm, I do not see how. As far as I know, you need logic to do that once you catch them, which we could also put in.</div>
<div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888"><br>
   Barry<br>
</font><div><div></div><div class="h5"><br>
><br>
> I think we should retain the code for interoperability with C++-heads.<br>
><br>
>    Matt<br>
><br>
> --<br>
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
> -- Norbert Wiener<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>