[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Java arithmetic overflow (was Re: the benefits of immutability)
> From: "Perry E. Metzger" <firstname.lastname@example.org>
> Date: 20 Aug 2003 13:25:30 -0400
> I would rather a program terminate on an unintended overflow than that
> it blithely continue running. There are huge numbers of dangerous and
> utterly silent errors that happen as a result of unnoticed arithmetic
> overflow, and figuring out where they happened is a royal
> bitch. Throwing an exception seems like a fine way of doing it, but
> really, anything else that is conspicuous would be fine.
> Of course, silently converting to a bignum if you haven't explicitly
> said a variable should only be a fixnum seems like a fine solution,
> too. In Java's model, though, an exception likely makes more sense.
> Perry E. Metzger email@example.com
Or you could have a compiler option that treated arithmetic overflows as
exceptions. No way the java developers would ever go for that, though.
They're heavily wed to the notion that the semantics should be identical
everywhere always, even if the semantics are broken (and from their POV it
Personally, I loathe languages that claim to be "safe" but don't trap
overflows or NaNs. I've seen too much numerical simulation code where a
single NaN propagates throughout the simulation, leading to garbage that is
never detected until a huge amount of time has been wasted. I know that
there are many issues involved, and it's as much the hardware's fault as
the language's, but I hate it anyway.