Re: Problem with function return

[Ray Blaak <blaak@infomatch.com>]

synoptik@home.com (A. Logue) writes:
> At work we have an informal standard to declare a "Nil" kind as the first
> kind for all enumerated types.  For example 
> 
> type color_kind is (nil, red, green, blue);
> 
> This works great in many cases where the return type cannot be determined 
> (for whatever reason), simply return a nil kind and let the function's 
> clients deal with the result.  i.e.  ignore and carry on, delay and retry, 
> etc.  

If nil is used to mean error, then it is actually better to raise an
exception. The client still then has the choice to ignore and carry on, delay
and retry, etc., but the error handling logic is clearly separated from the
normal logic, which makes things more understandable. 

If nil is used to mean "not specified yet", then its role is more useful. It is
a mistake to use it too much, however. I have been on projects where it was
mandated for all enumerated types, complicating logic and test cases for that
extra, often useless value. If the enumeration already sensically expresses all
possible values, the unknown/nil/undefined value is often superfluous.

For example,

 type WeekDay = (Sun, Mon, Tues, Wed, Thurs, Fri, Sat);

There are no other possible values. Now one still might want to express
undefined or unknown, so I would at least do this:

 type WeekDayValue = (Unknown, Sun, Mon, Tues, Wed, Thurs, Fri, Sat);
 subtype WeekDay = WeekDayValue range Sun .. Sat;

I would try to stick to the restricted one as much as possible, and use the
more general one only when necessary (i.e. converting from external inputs,
etc.).

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.