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]

Re: GSL Error Handling


"Gregory R. Warnes" wrote:

> On Sun, 16 Jul 2000, E. Robert Tisdale wrote:
>
> > GSL functions should NOT return error codes!
>
> I STRONGLY disagree.
> Error checking is a critical part of any reliable software system.

I agree.
But GSL functions still shouldn't return error codes.
You know as well as I that most numerical application programmers
are going to ignore the error codes returned by most GSL functions
because they know that the arguments can't generate errors
and the error checking is unnecessary.
I suppose that you could have two versions of each GSL function --
one that does error checking and one that doesn't --
or you could have a GSL function to just do the error checking
before you call a GSL function that doesn't do error checking.

> > Programming errors are always unanticipated
> > 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.

Some run time programming errors are difficult to detect and debug.
The application programmer should be able to compile and/or link
a version of the GSL that does extensive checking
for programming errors at run time.
But programming errors are always unanticipated.
If you could anticipate a programming error, you would just fix it.
You wouldn't write extra code to detect and "handle" it.

> > 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. [...]
>
> 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.

Who is the user?
Is the user an application programmer?
If so, then you can provide optional error checking code
that the application programmer can compile and/or link in
to help detect and debug programming errors during testing.
If the user isn't the application programmer,
it probably won't help to detect and report programming errors
because the user won't be able to do anything about them.
A professional programmer who writes applications
for other people to use must do extensive testing
before releasing the application to the user.
Once testing is complete, the application program
can be re compiled and/or linked to a version of the GSL
that doesn't do any checking at all at run time
for programming errors.

You seem to have confused programming errors
which CANNOT be anticipated or handled
with exceptions and events
which CAN be anticipated and handled.
Adding two vectors of different lengths together,
for example, is a programming error.
Application programmers should compare
the lengths of the two vectors
before they attempt to add them together
if they anticipate that
the vectors might have different lengths.

> > If performance is important, the application
> > should be compiled and/or linked
> > without error checking code
> > before it is placed into service.
>
> In my experience,
> most users are willing to accept a sizable performance loss
> in exchange for the assurance that errors will be detected and clearly reporte

d.
> Fortunately, computers are fast enough now that
> the performance loss associated with checking for errors is usually negligible

.

Use Mathematica, Matlab or Maple
if you don't care about performance.
Most numerical application programmers use Fortran or C
because they do care about performance
and they are insanely jealous of every wasted CPU cycle.
The cost of checking for programming errors at run time
is not negligible.
You cannot check every invocation of gsl_vector_get
for a subscript out of bounds, for example,
without a serious performance penalty.
You can have high performance numerical computing or
you can have run time error checking
but you can't have both.

> 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.

Whether error checking is the default or not
should be left up to the library developer.
The problem is that the GSL API specifies that
GSL functions return an error code
so you can't turn off run time error checking
unless you change the GSL API.

> > 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.
>
> 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
> (i.e. 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.

What are your priorities?

    0. performance
    1. safety
    2. convenience

Who are the users?
Amateur numerical application programmers
who write programs for their own use?
Or professional numerical application programmers
who get paid write programs for other people to use?
These two distinct groups of numerical application programmers
have very different priorities.

It seems to me that programmers
who write numerical applications in ANSI C
are probably more concerned about performance
than safety or convenience.
It would probably be better to use an Ada language binding
if safety was the highest priority or a C++ language binding
if convenience was the highest priority.

All I am saying is that, if you are going to include
runtime checking for programming errors,
it should be a compile time option like this:

        inline gsl_double
        gsl_vector_get(const gsl_vector* v, gsl_offset j) {
          gsl_handle h = gsl_vector_handle(v);
          gsl_offset o = gsl_vector_offset(v);
          gsl_stride s = gsl_vector_stride(v);
        #ifdef GSL_CHECK_RANGE
          gsl_extent n = gsl_vector_extent(v);
          if (j >= n) {
            const double zero = ZERO;
            GSL_ERROR_RETURN ("index out of range", GSL_EINVAL, zero);
            }
        #endif GSL_CHECK_RANGE
          return gsl_handle_get(h, o + (gsl_stride)j*s);
          }



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