Re: Handling invalid objects

[Justin Gombos <rpbkbq.xax.gld@uluv.kbq>]

On 2006-03-18, Jeffrey R. Carter <spam.not.jrcarter@acm.not.spam.org> wrote:
>
> There's a basic SW-engineering principle that one thing should have
> one meaning.  Using one thing with 2 meanings, which is what you're
> asking for, clearly violates that principle.

That's a good point.  Given that perspective, would you say the
practice of using null access values to indicate whether the access
value is useable violates this principle?

>>   type clock_type is mod 12;
>> 
>>   function hour_of_day return clock_type;
>
> This seems to specify a function that is expected to always be able
> to return a valid value. 

Pretend that there are cases where the hour of day is unavailable.  I
chose an example using mod only because it has added complications
when increasing the range of values to allow for an invalid object,
and hour of day is simple.

> If it is expected to only be able to return a valid value some of
> the time, that should be documented, probably by naming the function
> something like Try_To_Get_Hour_Of_Day.

There's that principle of naming non-boolean functions nouns, since
they return an object.  Also, if an API is often queried for
information that it cannot retrieve, and often this is normal
operation, subprogram prefixes like "try_to_get_" seem lengthy.  I
would have to use some other means to indicate that the returned value
may be unusable.

> If the function should always be able to return a valid value, and
> it can't, that is clearly an exceptional situation, and an exception
> is clearly the correct way to deal with such a situation.

I recall working to a coding standard that barred exception raising
when other mechanisms for error detection are possible.  It
effectively banned exception raising altogether because you can always
send an error notice by other means.  Exceptions are synonymous with
goto statements, with the additional effect of creating an
unpredictable state so I didn't challenge the rule.

Exception raising and handling is often viewed as writing code that
will never execute.  Predefined exceptions must be handled when there
is an expectation they will be raised, but their usefullness stops
there.  Beyond that, it's like writing erroneous code on purpose.

> If valid values are not always possible, then it's a question of how
> often they are not available. If it's a fairly common occurrence
> (and that can be less than 50% of the time), then it's not an
> exceptional situation, and an unconstrained record type with a
> Boolean discriminant is probably the best thing to return.  If, on
> the other hand, it's a rare occurrence, then it's still an
> exceptional situation, and an exception is the correct solution.

I try to avoid variant records, but this sounds like a good use for
them.  I'll have to try that.

> Anyone who has seen C code that correctly checks and deals with all
> returned error codes and success flags knows how complicated and
> unreadable such code is.  The common practice in C is to not do the
> necessary checks so that the code is simpler and more readable. That
> is clearly not an acceptable solution.  Exceptions separate the
> normal processing from the exceptional processing, allowing simple
> and readable code for the normal case while ensuring that all checks
> are performed and dealt with.
>
> There are cases where exceptions are outlawed; most of them are not
> justified.  Even if they were all justified, advocating a return to
> the mess that error codes create is not a viable option.

It's a mess regardless.  Clearly Ada is deficient in this respect, as
all languages seem to be.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.