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

[John Lato]

On Mon, Mar 30, 2009 at 11:03 PM, Henning Thielemann
<lemming at henning-thielemann.de> wrote:
>
> On Sun, 29 Mar 2009, John Lato wrote:
>
>> On Sat, Mar 28, 2009 at 9:49 PM, Henning Thielemann
>> <lemming at henning-thielemann.de> 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