Style question: returning error values from functions

[Dar Scott]

On Saturday, July 12, 2003, at 06:11 AM, Richard Gaskin wrote:

> When crafting a function it's often useful to provide info about any  
> errors
> that occur within it.

Arg.  Thought I answered on this list, but did on the other.  I wrote  
this:

> On Saturday, July 12, 2003, at 06:11 AM, Richard Gaskin wrote:
>
>> Which approach do you prefer?  One of these?  Something else?
>
> I use these:
>
> 1.  Reshape the semantics so there are no errors.
> 2.  Throw
> 3.  Value returned in referenced variable and success/fail (or  
> related) returned.
> 4.  Separate domain validation functions (used before instead of  
> after) with, perhaps, #2 or #10
> 5.  Callback (very rarely for functions; I'll ignore this)
>
> Sometimes #1 is like your "error" prefix but not always.  For example,  
> char 5 of "abc" returns a reasonable value, empty, rather than an  
> error. In this approach what is reasonable depends on the function.   
> Another #1 approach is to define a way to coerce parameters to the  
> nearest closest value.  A general scheme can be used for numbers that  
> uses rounding and bounding as needed.
>
> The callback might reduce to changing a global error to a local error.
>
> These are also acceptable to me:
> 6.  Global
> 7.  Function like sysError()
> 8.  Error returned in referenced variable in parameters
> 9.  Use NaN, +Inf, etc for numerical functions (like #1)
> 10.  Let the function throw error or return garbage; used with #4
>
> Revolution built-in functions and operators use 1-3.  Of #1 some  
> return reasonable values and some coerce parameters to the function  
> domain.
>
> I readily use throw in scripts for my own use.  I also have used it in  
> a library I will make generally available, and I'm thinking of  
> changing the scripts so that they do not throw.  Are people  
> comfortable with throw?
>
> The value of functions is that you can use them in expressions.  If  
> you have to check after each use, then you lose the benefit.  That  
> makes #2 (throw) with perhaps #4 (data checking beforehand) more  
> interesting.

Dar

************************************************************************ 
****
   Dar Scott Consulting    http://www.swcp.com/dsc/    Programming  
Services
************************************************************************ 
****