[petsc-dev] ierr and CHKERRQ stuff

[Barry Smith]

  Somewhat related note: We have 

#define PetscStackCallHypre(name,func,args) do {                        \
    const char *_fname = name ? name : #func;                           \
    PetscStackPush(_fname);ierr = func args;if (ierr) SETERRQ1(PETSC_COMM_SELF,PETSC_ERR_LIB,"Error in %s()",_fname);PetscStackPop; \
  } while (0)

my thought was eventually to wrap all calls to external packages in something like this.

    Barry


On Oct 30, 2012, at 8:06 AM, Anton Popov <popov at uni-mainz.de> wrote:

> Good idea, I will use PETSC_CALL instead
> 
> On 10/30/12 1:52 PM, Karl Rupp wrote:
>> 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
>>> 
>> 
>