On Mon, Dec 7, 2009 at 5:30 AM, Ben Franksen
Michael Snoyman wrote:
On Sun, Dec 6, 2009 at 12:55 AM, Henning Thielemann < lemming@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
You're right; bad programmers could do this. A good programmer will know to do one of two things when it gets an exception it does not know how to handle:
* Die with an error message. * In cases like web servers, print an informative error message (eg, hopefully more useful than "Prelude: head") and continue doing something else. I think the kind of programmers who just ignore exceptions and try to keep going are what I think of as over-defensive programmers, who in a misguided attempt to make their code more robust think that they should eliminate any possibility of not returning a result. I saw my share of this kind of code at my previous job, and when you're dealing with data processing programs, it's *very* irritating when suddenly you have garbage data because someone thought "huh, this should be negative, will just use the abs function." However, these people will find ways of doing these evils even without exceptions. Bonus: My favorite error-handling line of code at the company was a bit of VBA that went: On Error Goto Hell Michael