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


Gerard Jungman wrote:

> The problem with library design in this area is not that
> there is too much "side-band" interaction with the application,
> but too little.  Applications need to know what is going on
> in a numerical implementation.  They have a right to know.
> The problem is arranging some form of communication channel
> without breaking encapsulation.  This is not an easy problem
> and archaic languages make it nearly impossible.
> So we are stuck with "error codes" for now.

No.  You are stuck with "error codes"
because you have failed to imagine a better alternative.
If application programmers fail to examine the error code,
error checking will be wasted and the error may go undetected.
You would still need to provide an option to compile and/or link
in code to report the error to application programmers
in case they forget to examine the error code
and/or handle it appropriately.
If you want to force application programmer
to handle errors, exceptions or events,
GSL functions should require them to pass a pointer
to a handler object of the appropriate type for the function.


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