On Mon, Dec 7, 2009 at 2:13 PM, Henning Thielemann
<lemming@henning-thielemann.de> wrote:
Michael Snoyman schrieb:
> > 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.