On Tue, 8 Dec 2009, Ben Franksen wrote:

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.

Michael, you are above arguing that it is ok to use the same /mechanism/ to signal errors and exceptions. That is ok with me.

I'm actually arguing that errors and exceptions (or failures) should not be treated the same way. This is my opinion because 1. You cannot catch all kinds of errors (infinite loops, memory corruption, and so on) at run-time 2. The program cannot help itself if it is buggy. The next higher level in the software hierarchy certainly can, but this requires obviously a different mechanism. The correct treatment of those things is in my opion: 1. Errors must be fixed by the programmer 2. Exceptions must be appreciated by the programmer and handled by the program at runtime

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.

I used the term "exception" because this is the term used for the concept of handling "file not found", "could not allocate resource" in the introduction to modern languages that I have read. Thus my impression was that "exception" is the term for the concept, whereas there are different implementations and ways of handling them. For instance in Modula-3 the EXIT statement is called an exception that escapes the LOOP structure, but it cannot be catched with TRY, that is used for user defined exceptions. http://www.cs.purdue.edu/homes/hosking/m3/reference/exit.html In Modula-3 a detected error (range violation, NIL dereference, division by zero) terminates the program. An undetected error (which is restricted to UNSAFE modules) can cause memory corruption and all those bad things, and cannot be handled in any way. Before exceptions got a special handling in programming language, they still existed. In C for instance they were expressed by return codes. The Wikipedia author also seem to consider "exception" to be the term for the concept, not for the implementation: http://en.wikipedia.org/wiki/Exception_handling "Exception handling is a programming language construct or computer hardware mechanism designed to handle the occurrence of exceptions, special conditions that change the normal flow of program execution."

On Tue, Dec 8, 2009 at 7:40 AM, Michael Snoyman wrote:

On Tue, Dec 8, 2009 at 1:25 AM, Ben Franksen wrote:

...

...

On Mon, Dec 7, 2009 at 9:53 PM, Henning Thielemann < lemming@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,

...

...

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

Michael Snoyman wrote: that 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