This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


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

Re: Returning status from C functions


On Wed, 26 Jul 2000, Ian Grant wrote:

> Can seasoned Scheme people give their opinions on these two approaches to 
> returning status from C functions.
> 
> I have a library function, func - say, that returns status as an integer.  In 
> the header file, as usual, there is a set of #defines allowing me to  write
> 
>      if (func() != FUNC_OK) .. etc
> 
> When I wrap this for guile, I could either return symbols FUNC_OK, 
> FUNC_FAILED_THIS_WAY, FUNC_FAILED_ANOTHER_WAY etc, or I could scm_sysintern 
> integers like
> 
>     scm_sysintern("FUNC_OK", SCM_MAKINUM(FUNC_OK));
> 
> and have my wrapper return scheme integers.
> 
> Which is better?  Thi points out that symbols can be used in a case statement 
> and the integer definition of FUNC_OK can't.  On the other hand I can see uses 
> for the integer value.  Of course it's easy to convert from one to the other 
> too - but which should be the default?

First, I suggest that you also consider to use catch and throw.  This may
be a better way to deal with failures.  It also allows to pass more
information to the error handler than just a symbol or an integer.

Second, if you don't want to do this, I suggest not to use integers.  If
you plan to do some clever arithmetics with the integer return values,
this is probably a bad idea, since then later changes to the error
messages become difficult:  Tests like (if (> err-msg FAILURE_TYPE_A))
often lead to bad code if you at some time have to provide an additional
type of error that does not fit nicely into the scheme that you once had
designed.  Further, you would have to add a couple of definitions to the
global namespace.  Well, you could put it into a module, but still.

An exception for this rule might be if this is a performance critical
part, but to judge from your example code, this seems bo be unlikely.

Best regards
Dirk


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