On Sun, 2008-11-23 at 01:40 +0100, Henning Thielemann wrote: > On Sat, 22 Nov 2008, Thomas Schilling wrote: > > > It's a pattern match error, implemented by throwing an asynchronous > > exception. The idea being, that we only have one mechanism (well, an > > synchronous exceptions, thrown via throwIO). > > > > Yes, I know that there's a difference between "error" and "exception", > > but I would argue that which is which depends on the program. For > > example, for most programs a pattern match error is a fatal condition, > > there's no sane recovery from it. OTOH, in a program like GHCi, a > > pattern match error in an executed statement is an exceptional > > condition, which we want to catch, so it doesn't kill GHCi. > > It's completely ok to run something in a sandbox and try to observe > errors. But that's debugging and I think there is no need to do this in > many places of an application. In general handling errors automatically is > not possible, because an error might also be if a program loops > infinitely. Thus one should not generally handle an error like an > exception.
In general I agree. I would advise against explicitly catching such exceptions just in the region where one is expecting them. That seems like bad design. On the other hand "top level" catch-all handlers that also catch such logic errors sometimes make sense. For example in a Haskell web server where we generate a page dynamically it makes a lot of sense to catch errors in the page-generation function, including pattern match errors, and produce a 500 error code response and log the error message. That's a case, rather like ghci, where some flaw in the program can and should be compartmentalised. There's no attempt to clean up the error but it is a modular system and there is a clear boundary where failures can occur without bringing down the entire system. Duncan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
