[petsc-users] Call multiple error handler

[Barry Smith]

> On Jan 11, 2017, at 7:00 AM, Florian Lindner <mailinglists at xgm.de> wrote:
> 
> Hey,
> 
> Am 10.01.2017 um 14:20 schrieb Barry Smith:
>> 
>> I do not understand what you mean. I hope this is C.
> 
> Yes, I'm talking about C(++).
> 
> I'm using PETSc functions like that:
> 
>  ierr = ISDestroy(&ISlocal); CHKERRV(ierr);
> 
> Unfortunately that is not alway possible, e.g. in this function:
> 
> std::pair<PetscInt, PetscInt> Vector::ownerRange()
> {
>  PetscInt range_start, range_end;
>  VecGetOwnershipRange(vector, &range_start, &range_end);
>  return std::make_pair(range_start, range_end);
> }
> 
> CHKERRV would returns void, CHKERRQ returns an int (iirc). Neither is possible here. But that is not my main issue here.
> 
> For non PETSc related functions, I do not use CHKERRV and alike.
> 
>> 
>> By default when an error is detected PetscError using PetscTraceBackErrorHandler returns up the stack printing the
>> function/line number then returning to the next function which prints the function/line number until it gets up to
>> the function main where it calls MPI_Abort.
> 
> Ok, we use petsc like that:
> 
> void myFunc() {
>   PetscErrorCode ierr = 0;
>   ierr = MatMultTranspose(_matrixA, in, Au); CHKERRV(ierr);
>   [... no further error checking ...]
> }
> 
> with the standard error handler this gives a nice traceback, but the application continues to run.
> 
> With a PetscPushErrorHandler(&PetscMPIAbortErrorHandler, nullptr); above these lines, that gives no traceback, just
> 
> [0]PETSC ERROR: MatMult() line 2244 in /home/florian/software/petsc/src/mat/interface/matrix.c
>    Null Object: Parameter # 1
> 
> and the application aborts.
> 
> I want to combine these two traits. Print a nice traceback like the first example, then abort, like the second example.

CHKERRABORT()

> 
> 
>> Now if one of the functions in the stack of functions is a user function that DOES NOT check a return code with
>> CHKERRQ(ierr) then bad stuff happens because PetscError will print part of the stack of functions but then the user
>> code (that ignores the error code) continues running generally causing bad and confusing things to happen.  This is
>> why we recommend always using CHKERRQ() in user code.
>> 
>> From the perspective of PETSc error handling there really isn't any difference between user code and PETSc code.
> 
> I understand that. But changing our application so that every function returns an error code and is checked using
> CHKERR* is not an option. The PETSc code is buried deeply in the framework.
> 
> 
>>> However, I want my application to be aborted with the PetscMPIAbortErrorHandler when an error occures.
>> 
>> Do you mean that in your code when you detect an error you want SETERRQ() to call PetscMPIAbortErrorHandler()  but in
>> PETSc code you want it to try to return through the stack printing the PETSc function/line numbers? You can do this
>> by making your own macro mySETERRQ() that is defined to be a call to PetscMPIAbortErrorHandler and using mySETERRQ()
>> to mark errors in your code.  Though I do not recommend this, better to use CHKERRQ() in your code and get error
>> tracebacks for PETSc code and your code.
> 
> Ok, I'll keep that option in mind...
> 
> Best,
> Florian
> 
>>> On Jan 10, 2017, at 6:42 AM, Florian Lindner <mailinglists at xgm.de> wrote:
>>> 
>>> Hello,
>>> 
>>> I really enjoy the verbosity (line number) of the default PetscTraceBackErrorHandler. However, I want my
>>> application to be aborted with the PetscMPIAbortErrorHandler when an error occures.
>>> 
>>> Can I instruct PETSc to call first one handler, then another one?
>>> 
>>> Thanks, Florian
>> 
>