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

[Henning Thielemann]

On Tue, 8 Dec 2009, Richard O'Keefe wrote:

> When I was working at Quintus, I came up with a classification
> which I can simplify something like this:

It's certainly possible to classify errors and exceptions in other (also 
more fine grained) ways ...

>  operating system fault
> 	Something bad happened (like a remote node going down) that was
> 	entirely out of your control.  There is nothing you can do to
> 	your program to prevent this.  Example: power failure.  It's
> 	still your problem to clean up on your way out.

This is an exception. Of course, if the machine your program runs on goes 
out of power, then neither exception handling nor debugging will help.

>  resource faults
> 	your program tried to do something possibly meaningful but
> 	the system ran out of some kind of resource (cpu limit,
> 	memory limit, disc quota, &c)
>
> 	You might respond to this by increasing the limit and trying
> 	again.

An exception.

>  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.

>  existence errors
> 	Your program tried to do something with a (typically external)
> 	resource that doesn't exist (missing file)
>
> 	Your program could be wrong but probably isn't.
> 	You will have to create the resource or provide a different name.

Exception

>  permission errors
> 	Your program tried to do something to a (typically external but
> 	not always) resource that you do not have permission to do
> 	(typically writing to a read-only file)
>
>        You may have named the wrong resource.  If not, you may have to
> 	get the permissions for the resource changed, or ask someone
> 	else to run the program.

Exception

>  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

Malformed constant file name in your program is an error but it will raise 
an exception. The fix is to correct the filename, but you will still need 
the exception handling, since also the file with the correct name might 
not exist.

>  postcondition errors
> 	Your program invoked some operation and the precondition for
> 	the operation was satisfied, but when it completed, the
> 	postcondition was not.
>
> 	The operation you invoked is broken.  If it's yours, you will
> 	have to fix it.  If the precondition was not strong enough,
> 	it may be your program at fault.  Otherwise, until you can
> 	get a fix from someone, you will have to program around it.

This is an error.


> Take the case of trying to write to "/dev/nul".  This is a permission
> error.  If the program is responsible for the name being what it is,
> it's a mistake in the program.  If the user typed the name in, it's
> the user's mistake.  You really can't tell without tracing each value
> to its origin.

Sure, the distinction exception/error depends on the source of the data 
that causes problems.