On Dec 8, 2009, at 12:28 PM, Henning Thielemann wrote:
representation faults your program tried to do something meaningful but the system was unable to represent the result (integer overflow, upper case of ΓΏ in a Latin 1 system, floating point overflow on a non-IEEE system, &c)
Your program isn't *wrong* but you will still have to change it.
It is the responsibility of the programmer to choose number types that are appropriate for the application. If I address pixels on a todays screen I will have to choose at least Word16. On 8-bit computers bytes were enough. Thus, this sounds like an error.
That kind of attitude might have done very well in the 1960s. In an age when Intel have demonstrated 48 full x86 cores on a single chip, when it's possible to get a single-chip "DSP" with >240 cores that's fast enough to *calculate* MHz radio signals in real time, typical machine-oriented integer sizes run out _really_ fast. For example, a simple counting loop runs out in well under a second using 32-bit integers. The programmer doesn't always have the information necessary to choose machine-oriented integer sizes. Or it might not offer a choice. Or the choice the programmer needs might not be available: if I want to compute sums of products of 64-bit integers, where are the 128-bit integers I need?
domain errors A precondition on the input arguments of an operation was not satisfied (e.g., X/0, sqrt(-1), malformed file name, head []).
Your program is definitely wrong.
X/0, sqrt(-1), head [] are errors
It depends on WHERE THE DATA CAME FROM.
Sure, the distinction exception/error depends on the source of the data that causes problems.
And sadly, the library does not know this, so the library cannot classify problems _that_ way.