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

[Michael Snoyman]

On Mon, Dec 7, 2009 at 2:13 PM, Henning Thielemann <
lemming at henning-thielemann.de> wrote:

> Michael Snoyman schrieb:
> >
> >
> > On Mon, Dec 7, 2009 at 5:30 AM, Ben Franksen <ben.franksen at online.de
> > <mailto:ben.franksen at online.de>> wrote:
> >
> >     Michael Snoyman wrote:
> >
> >     > 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:
>
> It is certainly not the task of a programming language or a library to
> parent its users. Despite an interesting idea, it will not work, since
> programmers will simply switch to a different language or library if
> they feel pushed around.
>

How did you get from what I said that I have any desire to parent users of a
language? I think my sentiment is clear: a bad programmer will do bad things
with any tool. I don't care about how a bad programmer might screw things
up.

In fact, I think your ideas are much more likely to give the feeling of
being "pushed around." The only opinion I've stated so far is that it's
ridiculous to constantly demand that people follow your definition of error
vs exception, since the line is incredibly blurry and it buys you very
little.

However, my opinion on what libraries should do is simple: Provide a simple,
uniform interface for receiving both errors and exceptions, and let the
library user decide what to do with them. If they are unhandable, then don't
handle them; if a user *does* handle something which can't be dealt with,
they fall into the over-defensive bad programmer category and I don't care.
Otherwise, it gives people the flexibility that they need in all cases.

I think under no circumstances* should a library simply terminate a runtime
because it decides to. This is one of the great things of being able to
catch all errors.

* Of course, there are no absolutes. Ever. Not a single one.

>
> There is an important reason to not simply catch an error and proceed as
> if it were only an exception: The error might have corrupted some data
> and there is no general way to recover from that. Say, after detecting
> an error you might want to close a file that you were working on. But
> since you are coping with an error, something you did not foresee, you
> cannot tell whether the file was already closed again or never opened.
> So it is better to just abort the program.
>
> The next higher level, the shell calling your program or the browser
> calling your plugin, might have registered what have opened and
> allocated and can reliably free those resources.
>
> And what if you're calling a library in the same runtime? I think you are
conflating the idea of "treating errors as exceptions", which I think is a
good one, and "not letting there be any distinction between errors and
exceptions," which is a bad one. The fact that I can use
Control.Exception.catch to catch either errors or exceptions, but I can
differentiate based on the data type, is IMO a great solution to this issue.

I also believe that the failure package is a better** solution to the
problem, because it makes it exceedingly clear which error/exception might
have occurred.

** Of course, failure cannot handle a lot of what IO exceptions can, so it's
a silly comparison in general. However, for the purpose of "good
error/exception handling," I think it's a better solution.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091207/519c00dd/attachment.html