> On Jan 11, 2017, at 7:00 AM, Florian Lindner <[email protected]> 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 <[email protected]> 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 >> >
