On Dec 5, 2009, at 3:00 PM, Michael Snoyman wrote: > I think we can all appreciate why it would be a bad thing is we treat > exceptions as errors. For example, I don't want my program to crash on a file > not found. > > On the other hand, what's so bad about treating errors as exceptions? If > instead of the program crashing on an array-out-of-bound or pattern-match it > throws an exception which can be caught, so what?
As I understand it, an error is a problem which aborts a computation and an exception is a problem that simply needs to be dealt with before the computation can continue. You are correct that there should be as few irrecoverable errors as possible in an application. In particular, if we think of an application as being a whole bunch of sub-computation tied together into a larger computation, then in a sense what we want is for no the failure of no sub-computation to cause the whole application-wide computation to fail. This, however, does not mean that there will be no circumstances under which any sub-computation fails, such as in the case of discovering in the middle of leading a file that it is irrecoverably corrupt. When these circumstances occur, one has an error and not an exception because there is no way to finish loading the file. However, at a higher lever, the sub-computation of loading the file was not necessary for the application to keep running, and so an error in the sub-computation becomes merely an exception when propagated up to the application level. Cheers, Greg _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
