[MOAB-dev] [PATCH] scdtest.cpp: print what failed on error

[Jason Kraftcheck]

Jed Brown wrote:
> On Mon, 30 Nov 2009 11:26:29 -0600, Jason Kraftcheck <kraftche at cae.wisc.edu> wrote:
> 
>> But I would still do something like:
>>
>> #define error(err) error_((err), __FILE__, __LINE__ )
> 
> In this case,
> 
>     error_((err),__FILE__,__LINE__,__FUNCTION__,#err)
> 

__FUNCTION__ is not portable.  The first standard to include an equivalent
was the __func__ "macro" in C99.  But C99 isn't yet part of the c++
standard.  The correct way to do this is to provide configure logic that
tries a bunch of common "macros", and if none is found, defines it to be an
empty string.

>>   a) are typesafe
> 
> The assignment to an MBErrorCode achieves the same.
> 

True, but then you have to declare a local variable for which the compiler
is likely to warn about if there is a variable with the same name in the
scope in which the macro is expanded.  An inline function avoids all of
these issues, allows one to set a breakpoint within the function as a
convenient way to stop when an error occurs, and has no disadvantages that
I'm aware of.

>>   b) allow setting of break points easily, and
> 
> Agreed, though MPI_Abort also works.
> 
>>   c) avoid multiple executions of an expression if the macro
>>   argument is an expression.
> 
> Hence saving the error code in the body of the macro.
> 
>> As you began with changing the function to a macro, and then added the
>> location stuff with your second patch, it seemed that perhaps printing the
>> location was not your only motivation for changing the function to a macro.
> 
> abort() prints the line number and the statement that failed, so even
> the first one (admittedly a half-ass job) was a lot more useful than the
> old one.  Having the macro call a function is a more complete solution,
> though approximately equivalent in this case.  To get real benefit, it
> should call via a function pointer so that you can change the error
> handler at runtime.
> 

For conditional tests within test code, I think that user-defined error
handlers are unlikely to ever be used.

> If you want to define a standard way of handling errors within MOAB,
> rather than incompletely duplicating it in each test suite, then it's
> worth doing it carefully with appropriate indirection, 


I think that conditional checks within tests can probably be done
independently from an improved error handling mechanism in MOAB.  A fully
featured error handling mechanism is important for applications, but
overkill for tests.  And we already have a better error checking mechanism
defined in TestUtil.hpp.  It just wasn't used when writing this test (and
may not be appropriate for use in parallel.)

> I just wanted a
> good enough error message to know that I didn't have to investigate.
> 

I understand that part.  I don't care much for the idea of changing from a
function to a macro, but on the other hand, it is just one test so it isn't
a big deal.

- jason