This is the mail archive of the gsl-discuss@sources.redhat.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

GSL Error Handling


GSL functions should NOT return error codes!
Error detection implies error checking
which can be very costly on some platforms.
Run time error checking should be an option
which the application programmer can select
at compile and/or link time without changing
any of the application program source code.

Programming errors are always unanticipated
so it isn't possible to handle them.
The only thing that error checking code can do
about a programming error detected at run time
is to report the error to the programmer
and continue processing if possible.
Checking for programming errors is pointless
once the programmer has finished testing
and placed the application into service
because the user probably won't be a programmer
and wouldn't be able to fix the bug anyway.
If performance is important, the application
should be compiled and/or linked
without error checking code
before it is placed into service.

Runtime error checking and handling
should be left up to application programmers.
The result should be undefined if, for example,
the source and destination vector views
in GSL function

  void
  gsl_vector_memcpy(gsl_vector*, const gsl_vector*)

differ in extent.
If application programmers expect errors,
then they should be obliged to include code

  if (gsl_vector_extent(pu) == gsl_vector_extent(pv))
    gsl_vector_memcpy(pu, pv);
  else
    fprintf(stderr, "Vectors u and v differ in extent!\n");

to detect them and take appropriate action.
Functions like gsl_vector_memcpy might be redefined
to return a pointer to the destination vector

  gsl_vector*
  gsl_vector_memcpy(gsl_vector*, const gsl_vector*)

instead of an error code which can be passed
to other GSL functions which accept a pointer
to a gsl_vector as an argument.

  /* u = v + (t = w - x) */
  gsl_vector_add(&u, &v, gsl_vector_sub(&w, &x, &y));

This means that the GSL should avoid
specifying functions such as a matrix inverse
which conceal the generation of errors
from the application program
in favor of functions like matrix decompositions
which expose errors to the application program.

The GSL should not use exception handlers to modify
the behavior of functions on domain or range errors.
Different functions should be provided
if different behavior is expected.

Some platforms provide special hardware to detect
domain, range and other floating-point exceptions
Application programmers can take advantage
of these features by installing standard
but not necessarily portable exception handlers.
The GSL function which installs each type
of error handler should issue and informative
warning message the application programmer
if the implementation does not support
the exception handler.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]