On Mon, Dec 7, 2009 at 9:53 PM, Henning Thielemann < lemm...@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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe