[petsc-dev] How far should internal error checking go?

[Jed Brown]

I don't know what the question is.  You can `git grep PETSC_ERR_PLIB` for places where we are checking for corruption in something that PETSc has produced.  When those checks are expensive (like checking if indices are sorted), they use `if (PetscUnlikelyDebug(cond)) { ... }` or `if (PetscDefined(HAVE_DEBUG)) { ... }`.

Jacob Faibussowitsch <jacob.fai at gmail.com> writes:

> Hello All,
>
> How far should one go in error checking when using #if defined(PETSC_USE_DEBUG)? So far I have gone with the mantra that internal petsc routines (including ones authored by myself) should be considered infallible and that I should only be checking for garbage *input* from the user. But there is not a person in existence that doesn’t write buggy code, as evidenced by the somewhat routine “fixing bug in XYZ” merge requests one sees. 
>
> On the other hand it is also not reasonable to check every single output with a fine-tooth comb because for the majority of cases code written by petsc developers is working as intended. Take for example writing an array sorting algorithm. Since every operation is "performance critical” these are often written in less logical or less readable formats leading to some subtle bugs that the writer doesn’t immediately catch. If these remain uncaught through CI/CD and then bleeds into a user code I see absolutely no chance of the user (or even other devs) ever being able to identify that the sorting algorithm deep in some function stack is the one producing the bug without significant effort. One could include a “dumb” version of the same algorithm that checks a copy of the initial array for missing/misplaced elements but as mentioned above this is a pointless slowdown 99% of the time. 
>
> CI/CD -- while excellent at catching a lot of machine-specific bugs -- isn’t bulletproof either. It relies on the assumption that the writer knows all possible sources of bugs in their code and provides a test case for each, but to quote Isaac Newton “what we know is a drop, what we don’t know is an ocean”. I have been mulling over this problem for a while now, and have looked through the user manual/developers manual but have not found a definitive answer. 
>
> Best regards,
>
> Jacob Faibussowitsch
> (Jacob Fai - booss - oh - vitch)
> Cell: (312) 694-3391