On Mon, Dec 7, 2009 at 9:53 PM, Henning Thielemann <lemming@henning-thielemann.de> wrote:

On Mon, 7 Dec 2009, Michael Snoyman wrote:

I actually *did* read your article, and don't know what you are referring to.

If this is true, sorry, I didn't had the impression.

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