Re: >>: Exceptions vs NaN/NaI
On May 29 2012, Vincent Lefevre wrote:
On 2012-05-07 18:05:29 +0100, John Pryce wrote:
However IEEE754-2008 §5.10 defines the *totalOrder* predicate:
"totalOrder(x, y) imposes a total ordering on canonical members of
the format of x and y".
Does this predicate really make sense? Is the goal to be able to
sort numeric datums in a predictable way, or has it another use?
Is it used in practice?
No. Yes. No. Dunno.
The reason that it doesn't make sense is that the vague idea of using
NaNs for out-of-band data never was compatible with using them for
error indicators, and that the preservation of NaN values is at best
unreliable (e.g. "should" rather than "shall"). I have seen that
issue (a long time before IEEE 754!) cause a library to be unable to
retrieve the values it inserted into a hash table.
Perhaps one could allow language exceptions instead of NaN. For 754
formats, NaN in the data type would be mandatory and would follow
(B2), but the behavior could be the one specified by IEEE 754 (see
its Section 8 "Alternate exception handling attributes").
As I and others tried to get them to understand, the LIA-1 basic model
trap-diagnose-and-terminate is easy to implement, actually what most
programmers need, and tried and proven by 5 decades of experience. We
failed. Yes, it could be that, and that should be a required option,
unlike in IEEE 754.
The problem in most programming languages - as with the use of NaNs in
an IEEE 754 fashion - is specifying recovery. C++ essentially uses
exceptions only for resource recovery, and any complex objects being
updated when an exception occurs will be corrupted. I don't know Java
well enough, but would assume the same.
The simple, reliable and useful specification is to state that such a
failure raises an exception, the implementation is required to produce
a suitable diagnostic and take appropriate action (which might involve
termination). Vague, yes, but it makes the intent clear. That option
is for locating errors.
Regards,
Nick Maclaren.