Re: Handling invalid objects

["Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk>]

On Sat, 18 Mar 2006 09:57:24 +0100, Jacob Sparre Andersen wrote:

> Justin Gombos wrote:
> 
>> 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.
> 
> No.  The way to do that is to have proper values for all the states
> you want to handle, i.e.:
> 
>    type Hours is mod 12;
> 
>    type Clock_Type (Is_Set : Boolean := False) is new
>       record
>          case Is_Set is
>             when True =>
>                Time : Hours;
>             when False =>
>                null;
>          end case;
>       end record;

This is exactly the way I would expect this problem would be solved.
It's one of the reasons for variant records.  But it is still
a bit messy (more verbose, extra component in names).
Writing a generic just for one type is even more verbose, but in
some fields you have a lot of invalid data around!

In my field of stock trading, time series often have holes,
probably erroneous values, and other problems and discrepencies.
Tracking bad data, while keeping the code simple would be nice!

It'd be great if the language allowed me to set and propagate
invalid values naturally!  With floating point, a NaN is the
obvious choice.  When you see NaNs output by your code, you
know some/all of the calculation didn't work out properly.
With access types, null can sometimes be used this way.  But
a proper invalid value would be useful.  With integers, it
would seem very sensible to have a NaN as well.  Why did floats
get a NaN value, but integers didn't?  Languages often try to give
facilities that can map onto hardware efficiently.  But hardware
tries to give exactly what the languages need, but no more.
I think this vicious circle has made innovation with invalid
values hard, in spite of the usefulness in software design,
as well as hardware and software integrity.

Of course, back in the olden days, some machines (which?) had
ECC hardware, which generated an exception when invalid data was
fetched from memory, and programs could deliberately write invalid
bit patterns.  This could be exploited to catch bugs and keep
bad data from corrupting execution.  Nowadays, you can't do this
because the invalid bit patterns don't propagate through VM
and cache subsytems (even although caches and backing stores have
their own ECC).

VHDL, when modelling hardware logic has a comprehensive system
for tracking invalid values.  Often the invalid data is
irrelevant to the operation and valid data prevails.  Sometimes,
invalid data propagates and dominates.  Raising exceptions
all over the place cannot be a complete substitute.  Only by building
in data validity into the core of the language and/or hardware can you get
widespread adoption.  IEEE Floating Point shows it can be useful,
inexpensive and ubiquitious.  Programming guidelines, generic validity
wrappers and compiler options are a poor alternative.
--
Adrian