[petsc-dev] SETERRQ in fortran

[Smith, Barry F.]

> On Jan 5, 2018, at 12:45 PM, Jed Brown <jed at jedbrown.org> wrote:
> 
> "Smith, Barry F." <bsmith at mcs.anl.gov> writes:
> 
>>> On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin <bourdin at lsu.edu> wrote:
>>> 
>>> 
>>> 
>>>> On Jan 4, 2018, at 3:16 PM, Smith, Barry F. <bsmith at mcs.anl.gov> 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.