[Haskell-cafe] Re: New Hackage category: Error Handling
michael at snoyman.com
Tue Dec 8 01:05:12 EST 2009
On Tue, Dec 8, 2009 at 7:40 AM, Michael Snoyman <michael at snoyman.com> wrote:
> On Tue, Dec 8, 2009 at 1:25 AM, Ben Franksen <ben.franksen at online.de>wrote:
>> Michael Snoyman wrote:
>> > On Mon, Dec 7, 2009 at 9:53 PM, Henning Thielemann <
>> > lemming at henning-thielemann.de> wrote:
>> >> On Mon, 7 Dec 2009, Michael Snoyman wrote:
>> >> I also think that in an earlier mail I answered, that errors can leave
>> >> you with corrupt data, say invalid file handles, memory pointers, or
>> >> structures that violate invariants. You won't like to close files from
>> >> invalid file handles and free memory from corrupt pointers or run into
>> >> infinite loops by traversing the corrupt data structures. That's the
>> >> reason why it is better to stop execution of the program and hand over
>> >> control to the next higher level, say the shell or the web browser,
>> >> can free resources safely.
>> > Firstly: I'm really referring exclusively to non-FFI Haskell programs,
>> > which most of the issues you mention don't really apply. Nonetheless, I
>> > think that for a language with exceptions, it still makes sense to use
>> > exceptions in these cases.
>> > In all these cases, I think the correct thing is to have a specific
>> > exception type that is thrown that signals that it is such an
>> > unrecoverable error. This allows the programmer to do *whatever* they
>> > want. Perhaps they want to save some other data to a file before
>> > Perhaps they want to spawn a process to send in a bug report? Who knows.
>> > It doesn't matter. The point is, the user *might* want to do something,
>> > and exceptions let them do it if they wish, or they can completely
>> > that specific exception type and let the program crash anyway.
>> Michael, Henning
>> There are two meanings to the word 'exception' in this context; both of
>> tend to conflate these different meanings. One meaning is about a
>> *mechanism* for non-local control flow; the other is about certain classes
>> of un-desired program conditions.
>> Actually, I think you'll find the we are *not* conflating the terms.
> Henning makes it clear later on.
Let me rephrase that: we both agree that there is at least a theoretical
difference between the two. I believe the distinction in practice is
difficult, if not possible, to determine, while Henning disagrees (I
believe). Since I believe the two cannot in general be distinguished by
name, they should not be distinguished by mechanism, and thus individual
types of errors/exceptions/failures should be distinguished by type. I
believe Henning thinks that "errors" should cause a program to abort, while
"exceptions" should be handled by the exception mechanism.
So you're right: we do conflate the terms a bit. I *think* the conflation in
terminology, however, is directly correlated to the conflation in mechanism.
> Michael, you are above arguing that it is ok to use the same /mechanism/ to
>> signal errors and exceptions. That is ok with me. There are certainly good
>> use cases, you have presented a few. However, that does not mean it
>> is 'silly' or 'unnecessary' to distinguish between program(-mer) errors
>> other kinds of expected exceptional conditions in general, as you claimed
>> in a previous message.
>> I agree with Henning insofar as I think it is important to make the
>> *conceptual* distinction -- regardless of whether we use the same
>> to signal (and, perhaps, after serious consideration, handle) them.
>> So, maybe it would help if we could agree to use different terms for those
>> two meanings of the word 'exception'. I think 'exception' is too strongly
>> associated with the non-local control flow mechanism to introduce a new
>> word for it.
>> Henning, what about calling an undesired but expected condition a
>> instead of an exception, so we could reserve this word for the language
>> mechanism? Calling something a 'failure' in this sense (i.e. in contrast
>> to 'error') would always include some judgement, as it needs to take the
>> different program levels into account.
>> Please do *not* call them failures; a few of us have been working on a
> failure package and associated helper packages, and called it failure
> specifically because it was an unused term and thus incurred none of the
> wrath which rains down upon those unfortunate souls who conflate the terms
> error and exception in the descriptions of their issues.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe