[Haskell-cafe] Re: New Hackage category: Error Handling

[Richard O'Keefe]

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.