Re: Handling invalid objects

["Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org>]

Justin Gombos wrote:
> 
> The 'Valid attribute exists to be able to handle abnormal objects.

And it exists to handle results from outside normal Ada processing, such as 
values from hardware or from interfacing to other languages.

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.

You'll find plenty of code, including some things in the standard Ada library, 
that violate this principle. Nevertheless, it is rarely a good idea to violate 
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. 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.

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.

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.

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.

-- 
Jeff Carter
"The time has come to act, and act fast. I'm leaving."
Blazing Saddles
36