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

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

Michael Snoyman schrieb:

...

On Mon, Dec 7, 2009 at 5:30 AM, Ben Franksen mailto:ben.franksen@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