[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Consensus on error handling with DLMs

Randall Skelton <rhskelto@atm.ox.ac.uk> writes:
> Hi all,
> I've more or less finished writing an IDL interface to Postgres and I'm
> now in the debugging stage. I thought I'd take a poll to see what people
> think of appropriate error returns.  In this library I have a variety of
> function returns... integers, floats, doubles, strings, complex structures
> and so forth.  For integer returns, I usually default to giving the user a
> message with the handle IDL_MSG_INFO in IDL_Message and returning -1 on
> failure.  Is there a good protocol for signifying an error in strings,
> structures and arrays?  Some of my default string returns are themselves
> null strings (indicating that no data or message was found) so it wouldn't
> be wise to simply return a null string on error.  I am also very reluctant
> to return a float -1.0000 as testing for this can lead to problems with
> IEEE number definitions in C.  For the moment, I am using the
> IDL_MSG_LONGJMP to signal an error in all routines that don't return an
> IDL integer.  It stops the interpreter immediately (which isn't
> necessarily bad) as it signifies a major fault.  Comments?

It is common to have an independent status variable.  For example,
consider the ERROR keyword to OPENR.  This way users can test the
status variable before accessing the data.  If you do this, then upon
failure you can always return an integer 0 for the data.

Also, you might consider writing your internal routines as procedures
rather than functions.  The READF procedure, for example, accepts a
positional parameter which contains the new data upon return.  This is
nice because if there is an error you can simply not modify the
parameter.  Contrast this to IDL functions, where *something* must be
returned, and it's impossible to return an "undefined" value.

Good luck,

Craig B. Markwardt, Ph.D.         EMAIL:    craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response