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

[John Lato]

>
> Message: 8
> Date: Fri, 27 Mar 2009 10:41:05 -0700
> From: Jonathan Cast <jonathanccast at fastmail.fm>
> Subject: Re: [Haskell-cafe] Re: Exception handling in numeric
>        computations
> To: Gregory Petrosyan <gregory.petrosyan+haskell at gmail.com>
> Cc: haskell-cafe at haskell.org
> Message-ID: <1238175665.20367.12.camel at jcchost>
> Content-Type: text/plain; charset=utf-8
>
> On Fri, 2009-03-27 at 20:38 +0300, Gregory Petrosyan wrote:
>> On Fri, Mar 27, 2009 at 7:31 PM, Donn Cave <donn at avvanta.com> wrote:
>> > Quoth John Lato <jwlato at gmail.com>,
>> >
>> >> An exception is caused by some sort of interaction with the run-time
>> >> system (frequently a hardware issue).  The programmer typically can't
>> >> check for these in advance, but can only attempt to recover after
>> >> they've happened.
>> >>
>> >> An error is some sort of bug that should be fixed by the programmer.
>> >
>> > I have never felt that I really understood that one.
>>
>> Me too :-)
>>
>> BTW, John, how often do you encounter _hardware_ issues compared to "errors"?
>
> Can't speak for anyone else, but I usually encounter hardware issues
> just before I replace the hardware...

This is getting confusing with two "John"'s replying.

For myself, I do not encounter hardware issues often at all (unless
you count buggy drivers).  They are the exceptional condition.

>
>> Is an "out of memory" thing an error or exception?
>> You will say "exception, for sure", wouldn't you? :-)
>
> No.  GHC possesses an out-of-memory exception that (IIRC) it never
> throws, because it's simply not worth trying to recover from heap
> exhaustion.  Maybe 20 years ago it was, but these days a program that
> manages to exhaust space is almost certainly either buggy or poorly
> optimized.

I would have said exception, although I agree with the assessment that
it's not worth trying to recover from.

>
> An `error' is any condition where the correct response is for the
> programmer to change the source code :)
>
>> And if it is a
>> result of applying
>> known-to-be-very-memory-hungry algorithms to non-trivial input? Looks like
>> programmer's error, doesn't it?
>
> See above.

Due to their brevity, I sometimes find it difficult to understand
Jonathan's replies.  So at the risk of putting words in his mouth, I
will take an attempt to explain this further.  Keep in mind these are
my words, not his, and it's possible I have completely misunderstood
his point since I've only been using Haskell intensively for about a
year (and I have no formal CS training, and other biographical points
apply as well).

Running out of memory is an exceptional condition.  Doing something
that is likely to cause memory exhaustion is a programming error,
because it was the wrong solution to the problem.  Memory exhaustion,
the exceptional condition, is an end result of making the programming
error.  In this case (but not all), it is possible to treat the
symptoms by handling the exception, but the general solution is to
avoid the problem in the first place.

>
>> And I think I can provide lots of similar examples.
>>
>> If there exists separation between errors and exceptions, it should be
>> very strong
>> and evident — otherwise "casual programmers" like myself will need to
>> stare at the
>> ceiling every time they write something to decide what suits best.
>

I am not sure when I would every throw an exception in Haskell code,
short of re-raising from a handler.  Things that I would have used
exceptions for in C-sharp can be handled explicitly with Maybe or
Either, a style that I greatly prefer.

John

> Protip: try pacing instead of staring at the ceiling.
>
> jcc
>