[petsc-dev] CHKERRXX() to propagate errors from C

[Matthew Knepley]

On Wed, Oct 19, 2011 at 7:39 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> #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)
>
> Inside PetscError():
>
>   if (p == PETSC_ERROR_IN_CXX) {
>     const char *str;
>     if (eh->ctx) {
>       std::ostringstream *msg;
>       msg = (std::ostringstream*) eh->ctx;
>       str = msg->str().c_str();
>     } else {
>       str = "Error detected in C PETSc";
>     }
>     throw PETSc::Exception(str);
>   }
>
> 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.
>
> 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.
>

This was intended to get PETSc-like error checking from C++-style functions
that throw exceptions. This was mostly for code I
wrote I think. Your fix is fine.

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
return values. The stack does not get wiped out, you can still catch
specific errors, and propagate ones you do not catch.
Does anyone have any serious defense of exceptions?

I think we should retain the code for interoperability with C++-heads.

   Matt

-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111019/a0f7fe31/attachment.html>