My two cents:

I think your right, but there are some tough decisions one must make. I`ll make the statement that one should always set the value of @ERROR using EXIT(n). Having said that, here`s some scenarios:

If your function returns data, then you really (should) have no choice. Always set the value of @ERROR using EXIT(n). I would NOT recommend returning an error code as part of the data itself. Why ? Because its not really the standard (kixtart) way of doing things.

If your function doesn`t return any data. Then you got some decisions to make. Should you return the error code ? Should you return nothing and set @ERROR ? Should you do both ?

Looking to Kixtart for guidance isn`t much help because some kixtart functions (like commands) just set the value of @ERROR, while some return @ERROR and set @ERROR.

The nice thing about returning @ERROR is that folks can use your UDF in conditionals, kinda like the OPEN function, eg:

if open(1,"filename") = 0
...
endif

The "problem" with returning @ERROR is that folks will always have to "silence" your UDF if they are not interested in its return code:

$= open(1,"filename")

Sometimes its nice not to have to "worry" about silencing a function. But given that silencing is a quirk unique only to kixtart, and that UDFs are functions and NOT commands, I would suggest that you bite the bullet and do it the kixtart way, and that is to return @ERROR and set @ERROR.

The only exception to this might be highy specialized functions, functions that are more like procedures than anything else. Or for functions that rarely if ever fail (ie console writting functions) or has good error checking, applies lots of defaults and has flawless error recovery.

-Shawn

[ 15 April 2002, 14:39: Message edited by: Shawn ]