[petsc-dev] ierr and CHKERRQ stuff

[Anton Popov]

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
>>
>