Henning Thielemann <[email protected]> wrote:
> The usual example against clear separation of exceptions and errors is the
> web server which catches 'error's in order to keep running.
> However, the web server starts its parts as threads, and whenever one thread
> runs into an 'error', it is terminated, just like an external shell
> program, that terminates with a segmentation fault. So, yes an error might be
> turned into an exception, but these are rare cases. In
> general it is hard or impossible to correctly clean up after an error,
> because the error occured due to something that you as programmer
> didn't respect. The "error handler" could well make things worse by freeing
> memory that is already deallocated and so on.
I don't see that as an argument against 'clear separation', really. Having
_some_ way of dealing an error (from within a program), in special
circumstances doesn't preclude clearly separating how it's done from exception
handling. I always find it jarring when an HUnit test I've run tells me it
encountered an 'exception', when I'm testing pure code (nevertheless I'd also
find it annoying if the entire test run terminated because of a failed pattern
match).
With respect to the last point - isn't proving that a given program can't
corrupt its own RTS possible, even in the presence of errors?
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
