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

[Ben Franksen]

Michael Snoyman wrote:
> On Mon, Dec 7, 2009 at 9:53 PM, Henning Thielemann <
> lemming at henning-thielemann.de> wrote:
>> On Mon, 7 Dec 2009, Michael Snoyman wrote:
>> I also think that in an earlier mail I answered, that errors can leave
>> you with corrupt data, say invalid file handles, memory pointers, or data
>> structures that violate invariants. You won't like to close files from
>> invalid file handles and free memory from corrupt pointers or run into
>> infinite loops by traversing the corrupt data structures. That's the
>> reason why it is better to stop execution of the program and hand over
>> control to the next higher level, say the shell or the web browser, that
>> can free resources safely.
>>
> Firstly: I'm really referring exclusively to non-FFI Haskell programs, to
> which most of the issues you mention don't really apply. Nonetheless, I
> think that for a language with exceptions, it still makes sense to use the
> exceptions in these cases.
> 
> In all these cases, I think the correct thing is to have a specific
> exception type that is thrown that signals that it is such an
> unrecoverable error. This allows the programmer to do *whatever* they
> want. Perhaps they want to save some other data to a file before exiting?
> Perhaps they want to spawn a process to send in a bug report? Who knows.
> It doesn't matter. The point is, the user *might* want to do something,
> and exceptions let them do it if they wish, or they can completely ignore
> that specific exception type and let the program crash anyway.

Michael, Henning

There are two meanings to the word 'exception' in this context; both of you
tend to conflate these different meanings. One meaning is about a
*mechanism* for non-local control flow; the other is about certain classes
of un-desired program conditions.

Michael, you are above arguing that it is ok to use the same /mechanism/ to
signal errors and exceptions. That is ok with me. There are certainly good
use cases, you have presented a few. However, that does not mean it
is 'silly' or 'unnecessary' to distinguish between program(-mer) errors and
other kinds of expected exceptional conditions in general, as you claimed
in a previous message.

I agree with Henning insofar as I think it is important to make the
*conceptual* distinction -- regardless of whether we use the same mechanism
to signal (and, perhaps, after serious consideration, handle) them.

So, maybe it would help if we could agree to use different terms for those
two meanings of the word 'exception'. I think 'exception' is too strongly
associated with the non-local control flow mechanism to introduce a new
word for it.

Henning, what about calling an undesired  but expected condition a 'failure'
instead of an exception, so we could reserve this word for the language
mechanism? Calling something a 'failure' in this sense (i.e. in contrast
to 'error') would always include some judgement, as it needs to take the
different program levels into account.

Cheers
Ben