Re: GSL Error Handling

["Gregory R. Warnes" <warnes at biostat dot washington dot edu>]

On Sun, 16 Jul 2000, E. Robert Tisdale wrote:

  ERT>> GSL functions should NOT return error codes!

I STRONGLY disagree.  Error checking is a critical part of any reliable
software system.   

  ERT>> Programming errors are always unanticipated
  ERT>> so it isn't possible to handle them. [...]

In my experience is just the opposite.  There are many types of errors
that programmers make over and over.  Building a library that simply
fails when a common programming error occurs is poor design.  Building a
library that *silently* fails is gross negligence.

  ERT>> Checking for programming errors is pointless
  ERT>> once the programmer has finished testing
  ERT>> and placed the application into service
  ERT>> because the user probably won't be a programmer
  ERT>> and wouldn't be able to fix the bug anyway. [...]

This also disagrees with my experience.  I try to write code that
anticipates the various errors that could occur when calling library
routines so that appropriate action can be taken.  Sometimes the code can
deal with the error directly.  The rest of the time, it can at least
report the problem in a form that the user can understand.

  ERT>> If performance is important, the application
  ERT>> should be compiled and/or linked
  ERT>> without error checking code
  ERT>> before it is placed into service.

In my experience, most users are willing to accept a sizeable performance
loss in exchange for the assurance that errors will be detected and
clearly reported.  Fortunately, computers are fast enough now that the
performance loss associated with checking for errors is usually
negligible.

It seems reasonable to provide a mechanism for turning error checking off
when there is a particular need for maximum performance, but this should
NOT be the default.

  ERT>> Runtime error checking and handling
  ERT>> should be left up to application programmers.
  ERT>> The result should be undefined if, for example,
  ERT>> the source and destination vector views
  ERT>> in GSL function
  ERT>> 
  ERT>>   void
  ERT>>   gsl_vector_memcpy(gsl_vector*, const gsl_vector*)
  ERT>> 
  ERT>> differ in extent.
  ERT>>
  ERT>> If application programmers expect errors,
  ERT>> then they should be obliged to include code
  ERT>> 
  ERT>>   if (gsl_vector_extent(pu) == gsl_vector_extent(pv))
  ERT>>     gsl_vector_memcpy(pu, pv);
  ERT>>   else
  ERT>>     fprintf(stderr, "Vectors u and v differ in extent!\n");
  ERT>> 
  ERT>> to detect them and take appropriate action.

NO!  Computer scientists have been preaching Object Oriented programming
and before that Data Abstraction specifically to allow library routines to
check for these type of mismatches.  This is a class of programming errors
that is _very_common_ and is easy to check for in a library routines.

Libraries should be designed to help the user implement best practices.  
This includes reasonable error checking on arguments and error reporting
for algorithm problems (IE trying to invert a (numerically) singular
matrix).  Forcing every user to implement the error checking code cause
an *enormous* waste of the most expensive resource: programmer time.

As an example, does anyone remember how horridly unstable Microsoft
Windows 3.0 was?  It turned out that the primary problem was that the
applications programmers were calling library routines with improper
arguments.  Since there was no parameter checking in the librariesm, this
usually caused the system to crash.  When Microsoft added parameter
checking (in version 3.1) the system became much more stable.

-Gregory