[petsc-dev] ierr and CHKERRQ stuff

Karl Rupp rupp at mcs.anl.gov
Tue Oct 30 07:52:34 CDT 2012


Hi Vaclav,

you are of course free to define TRY for your needs. Defining a short 
TRY globally in a *library*, however, is pretty dangerous, as the 
preprocessor define may collide with existing user definitions of TRY. 
Using PETSC_TRY instead of TRY might 'solve' this first problem, yet
the example
 >    if (something) TRY( somefun1 );
 >    else           TRY( somefun2 );
you provided is (at least in my opinion) reason enough not to do it. :-)

Btw: For technical reasons you might want to instantiate 'ierr' inside 
TRY, otherwise 'ierr' needs to be defined in the enclosing scope, even 
though it appears to be never used when looking at the user code.

Maybe there are other reasons as well? Barry?

Best regards,
Karli



On 10/30/2012 04:27 AM, Václav Hapla wrote:
> Dear all,
> I probably don't see something important and I am sorry for that in
> advance, but anyway I want to make it clear to me:
>
> What would I spoil by using kind of
>    TRY( ... );
> concept instead of
>    ierr = ...;CHKERRQ(ierr);
> stuff?
> The first concept seems to me making the code more readable and is
> faster to type of course.
>
> I have the following two lines in one of my headers included by all C
> files:
>    static PetscErrorCode ierr;
>    #define TRY(f) {ierr = f; CHKERRQ(ierr);}
> and the PETSc' error catching system works normally I mean.
>
> I know of course that for instance following is wrong:
>    if (something) TRY( somefun1 );
>    else           TRY( somefun2 );
> which is a little bit nonintuitive.
>
> This is not against already existing code; I would just like to
> understand the reasons - if I am wrong I am about to switch my codebase
> to the original PETSc' concept.
>
> Thanks in advance,
> BR,
> Vaclav
>




More information about the petsc-dev mailing list