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