> On Jan 5, 2018, at 12:45 PM, Jed Brown <[email protected]> wrote:
>
> "Smith, Barry F." <[email protected]> writes:
>
>>> On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin <[email protected]> wrote:
>>>
>>>
>>>
>>>> On Jan 4, 2018, at 3:16 PM, Smith, Barry F. <[email protected]> wrote:
>>>>
>>>>
>>>> It's changed a bit. It is better but you need to understand how the new
>>>> one works, so take a few minutes to see how it works before converting.
>>> Got it.
>>> An example or a link to the fortran macro definition from the man page
>>> would be nice
>>> I am confused about the rationale for putting the endif in the macro,
>>> though.
>>
>> It matches the C paradigm
>
> Hardly.
It matches the paradigm as close as can be reasonable done.
I debated putting the then into the macros also.
> #define SETERRQ(c,ierr,s) then ;call PetscError(c,ierr,0,s);return;endif
So usage would be
if (bad) SETERRQ();
would that be better.
> This Fortran:
>
> #define SETERRQ(c,ierr,s) ;call PetscError(c,ierr,0,s);return;endif
>
> This would be like writing this C
>
> #define SETERRQ(c,ierr,s) return PetscError(...); }
>
> to be used like
>
> if (BAD) { SETERRQ(comm, ierr, "why")
>
> which is just bananas and still not as gross as the Fortran. You might
> not have noticed this because SETERRQ is not called from any of PETSc's
> Fortran examples.
But SETERRA() is and has the same pattern.
>
>>> Beside not having unmatched if / end if in my code, in a select case
>>> construct, I have to write something as ugly as
>>>
>>> select case (i)
>>> case(1)
>>> !do something
>>> case(2)
>>> !do something else
>>> case default
>>> if (0 == 0) then
>>>
>>> SETERRQ(PETSC_COMM_WORLD,PETSC_ERR_ARG_OUTOFRANG,”invalid value”)
>>> end select
>>>
>> What is ugly about this ? except that you put the SETERRQ on a new line
>> which you did not need to do.
>
> Reread the above code. Requiring the dummy opening if statement is nuts.
Agreed. He should not use SETERRQ() in this case, should call the error
functions directly)
>
>> How do you want to write it so it is prettier?
>
> SETERRQ should not include that endif. CHKERRQ has the opening if and
> thus needs the closing too (so it's as intended). Also note that your
> first reply to Blaise was talking about CHKERRQ when he was asking about
> SETERRQ.
Hmm, I'm not sure about. Oh well, it doesn't matter. You have convinced me
of anything.
