On Tue, Dec 8, 2009 at 7:40 AM, Michael Snoyman <mich...@snoyman.com> wrote:
> > > On Tue, Dec 8, 2009 at 1:25 AM, Ben Franksen <ben.frank...@online.de>wrote: > >> Michael Snoyman wrote: >> > On Mon, Dec 7, 2009 at 9:53 PM, Henning Thielemann < >> > lemm...@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 >> data >> >> 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, >> that >> >> can free resources safely. >> >> >> > Firstly: I'm really referring exclusively to non-FFI Haskell programs, >> to >> > 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 >> the >> > 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 >> exiting? >> > 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 >> ignore >> > 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 >> you >> 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 >> and >> 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 >> mechanism >> 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 >> 'failure' >> 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. > > Michael > Michael
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe