Re: [Haskell-cafe] Re: Exception handling in numeric computations

On Mon, Mar 30, 2009 at 11:03 PM, Henning Thielemann wrote:

On Sun, 29 Mar 2009, John Lato wrote:

...

On Sat, Mar 28, 2009 at 9:49 PM, Henning Thielemann wrote:

...

On Sat, 28 Mar 2009, John Lato wrote:

...

Honestly, me neither, until recently.  I'm only barely starting to understand it, and I do think there's a great deal of overlap.  Even if an error is a bug that can be fixed by the programmer, certain exceptional situations can also be fixed by the programmer by handling the exception, even if they can't be detected in advance.

For example?

A file not being written because of a permissions error.  This can't be detected in advance due to effects from other processes, but it's a predictable enough exception that the programmer should handle it for IO.

Indeed. However I still do not see the overlap of errors and exceptions. :-(

Really? You wrote in a prior email:

...

...

Btw. not handling an exception is an error.

An exception thrown at run-time reveals a programming error, and if the exception could not be thrown in this context then the error wouldn't exist either. The error is that the programmer did not deal with an exception. Conceptually I think the difference between errors and exceptions is clear, but many programming errors are a result of a lack or improper handling of exceptions. That's the overlap to which I refer.

 Handling of exceptions may mean that you print a message and abort the affected operation, that is you often do not need a specific exception handling. E.g. if the user wants to load a file into an editor, and the file is read-protected, then the editor reports, that the file cannot be loaded and does not load it. The editor should keep running, in contrast to when it detects a programming error. The same should happen when the editor encounters a memory overflow. So I cannot follow the argument of "memory exhaustion shouldn't happen anymore today, so there is no need to handle it". I remember this was claimed in this thread, too. However, recovering from a memory exhaustion can be tricky. Can the garbage collector still free memory, when it cannot allocate memory temporarily?

I thought the argument was that "when memory exhaustion occurs in a Haskell application, it is (usually) the result of a programming error." This means handling the exception and trying to continue work is not the proper approach to dealing with memory exhaustion.

...

...

Btw. not handling an exception is an error.

Agreed generally.  But some exceptions are likely in given contexts, others are not.  I don't think it's necessary to handle every possible exception, just the ones that are likely and predictable for a given activity.

Since handling of exceptions often consist of reporting the exception and aborting an operation, it should always be managable to handle all possible exceptions.

Manageable, but possibly not useful for all functions. I don't believe that anyone's advocating that all IO functions are wrapped in a 'try' or 'bracket', so long as there are exception handlers at appropriate levels. John