Re: Feedback from GSL folks on libflame 4.0

[Brian Gough <bjg at gnu dot org>]

> It seemed like a better idea to just get our attention so we could
> fix the problem. We agree that using return values would be a more
> standard way of handling errors, but we're also somewhat cynical in
> that we don't trust our users to check return values.

The approach in GSL is to have an abort() by default, for the same
reason.  But the user can turn off the abort() and use the error
return values instead by providing an alternative error handler as a
function pointer.  Here's how it would look with your functions:

=== FLA_macro_defs.h ===

// Error code translation and output macro definition.
#define FLA_Check_error_code( code ) \
  do { \
       if (code != FLA_SUCCESS) {  \
         FLA_Check_error_code_helper( code, __FILE__, __LINE__ ); \
         return code; \    /* see comment below about void functions */
       } \
  } while (0)


=== FLA_main_prototypes.h ===

typedef void FLA_error_handler_t (int code, const char * file, int line);


=== FLA_Check.c ===

static FLA_error_handler_t * FLA_error_handler = NULL;

void FLA_Check_error_code_helper( int code, char* file, int line )
{
  if ( code == FLA_SUCCESS )
    return;

  if (FLA_error_handler) 
    {
      (*FLA_error_handler) (code, file, line);
      return ;
    }

  if ( FLA_ERROR_CODE_MAX <= code && code <= FLA_ERROR_CODE_MIN )
  {
    FLA_Print_message( FLA_Error_string_for_code( code ),
                       file, line );
    FLA_Abort();
  }
  else
  {
    FLA_Print_message( FLA_Error_string_for_code( FLA_UNDEFINED_ERROR_CODE ),
                       file, line );
    FLA_Abort();
  }
}


(We actually have three macro GSL_ERROR, GSL_ERROR_VOID and
GSL_ERROR_VAL to handle different types of return value - error code,
void, and "other".  This is to avoid warnings about "returning a value
from a void function" etc).