Michael Snoyman wrote: > On Sun, Dec 6, 2009 at 12:55 AM, Henning Thielemann < > lemm...@henning-thielemann.de> wrote: >> On Sun, 6 Dec 2009, Michael Snoyman wrote: >> I think there are plenty of examples like web servers. A text editor >> with >>> plugins? I >>> don't want to lose three hours worth of work just because some plugin >>> wasn't written >>> correctly. For many classes of programs, the distinction between error >>> and exception is >>> not only blurred, it's fully irrelevant. Harping on people every time >>> they use error in >>> the "wrong" sense seems unhelpful. >>> >>> Hope my commenting on this subject doesn't become my own form of >>> *pedantry*. >>> >> In an earlier thread I have explained that one can consider a software >> architecture as divided into levels. What is an error in one level (text >> editor plugin, web server thread, operating system process) is an >> exception in the next higher level (text editor, web server, shell >> respectively). This doesn't reduce the importance to distinguish between >> errors and exceptions within one level. All approaches so far that I have >> seen in Haskell just mix exceptions and errors in an arbitrary way. >> > 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?
The error gets hidden instead of fixed? Cheers Ben _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe