[MOAB-dev] Error handling documentation/examples

[Vijay S. Mahadevan]

Paul, this really depends on whether the error that occurs deep in the
stack is fatal or not. If it is a show stopper, use MB_CHK_SET_ERR,
which will throw an error and produce the call stack. Otherwise,
anywhere up the line, you could handle this through
MB_CHK_ERR_RET/MB_CHK_ERR_CONT and use MB_CHK_ERR when you want to
throw an exception.

> Or once I have checked an
> error at a deeper level, is it less important to call the error macros as I
> return back up the stack?

Every time a non-zero error code is met, the stack is maintained until
a fatal MB_CHK_ERR or variant is called. Once a MB_SUCCESS is
encountered, this stack should be destroyed.

Danqing can you verify if this explanation is correct ? And perhaps an
example/test with both an expected fatal and non-fatal error from down
the stack should help here.

Vijay

On Sat, Feb 6, 2016 at 11:38 AM, Paul Wilson <paul.wilson at wisc.edu> wrote:
> Hi there,
>
> I have found all the error handling macros and mostly understand how they
> all work.  What is less clear is the best practice/convention for
> setting/returning errors down a deep call stack.  If method A calls method B
> calls method C calls method D, should I necessarily check for return values
> and apply error macros at each step in the stack?  Or once I have checked an
> error at a deeper level, is it less important to call the error macros as I
> return back up the stack?
>
> Any examples or guidance are welcome.
>
> Thanks,
> Paul
>
> --
> -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
> Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: http://go.wisc.edu/pphw-cal
> Professor, Engineering Physics. ~ http://cnerg.engr.wisc.edu
> Faculty Director, Advanced Computing Infrastructure ~ http://aci.wisc.edu
>