Handling invalid objects

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

On 2006-03-18, Randy Brukardt <randy@rrsoftware.com> wrote:
>
> You're confusing an "invalid" object with an "abnormal"
> object. Accessing an abnormal one is erroneous; surely you don't
> want to intentionally put that into your programs. (Remember,
> "erroneous" is Ada-speak for "anything at all can happen".)

The 'Valid attribute exists to be able to handle abnormal objects.

Here's a concrete example.  Suppose I have:

  type clock_type is mod 12;

  function hour_of_day return clock_type;

If hour_of_day gets called and for whatever reason I cannot return an
hour_of_day, the caller needs to know that.  Exceptions are a poor
choice.  The quality and style guide advises against them for a good
reason; exceptions are like gotos - and produce a questionable state.
It would be more graceful for me to return an invalid value (like -1),
so my caller can simply do a 'Valid to discover whether the operation
was successful.

So what are the choices?  

  1) Declare it as:

     type clock_type is mod 13;

     and add special handling code every time you increment or
     decrement the value to what you've chosen to be invalid.

  2) Wrap clock_type in a record, and include a validity flag.  Or
     loosely pass a flag back.  

  3) The hacker approach probably resembles something like this:

     invalid_hour_of_day : constant integer := -1;
     return_data         : clock_type;

     if cannot_get_valid_time then

       for return_data'address use invalid_hour_of_day'address

       return return_data;

     end if;

  4) Raise an exception.

Did I miss any?  They're all pretty sloppy.  The second choice is
probably the best one.  

Approach 2 on steroids: I previously worked on a team that had a
generic package called something like validated_object, where you
would pass in a type and it would return a private type which was
internally a record with a flag and your type.  Then you would call
the provided "valid" function to get the validity status, a set
function to set the status, and you'd have to call another function to
get at the data.  It was kind of a hassle to have to repackage things
whenever handling something that may be invalid.  It nearly doubled
the number of types we handled because every type would have the
validated version, but it was at least a way to pass objects that may
be invalid, and it was used uniformly throughout the project (as
opposed to each developer picking from any of the other approaches).