[Haskell-cafe] Re: New Hackage category: Error Handling

[Michael Snoyman]

On Mon, Dec 7, 2009 at 5:30 AM, Ben Franksen <ben.franksen at online.de> wrote:

> Michael Snoyman wrote:
> > On Sun, Dec 6, 2009 at 12:55 AM, Henning Thielemann <
> > lemming at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091206/11243bf8/attachment.html