[Haskell-cafe] Re: exceptions vs. Either

[Ketil Malde]

Alastair Reid <alastair at reid-consulting-uk.ltd.uk> writes:

> Do you just want exceptions to be displayed by an interpreter or do you want 
> them used in the compiler (i.e., part of the Haskell language).

I think it would be difficult, and perhaps undesirable, to make it
part of the language.  So my immediate thought was that an interactive
system could note any calls to functions that could produce exceptions
(e.g. performing file operations, division, calls to
undefined/error/fail, incomplete patterns...) and tell the user in the
response to the :i command.

> I think it is straightforward enough to annotate expressions with the 
> exceptions they can raise.

Oleg (reposted by Kean) manages this, but as far as I understand it,
it requires additional work by the programmer.

As I said, I don't have a lot of experience working with Java, but
cluttering the type( annotation)s with exceptions seems to be
tedious, especially when you really just want to propagate the
exception.  E.g. if I rewrite a function so that it no longer uses
division, I must potentially change all types up to the level where
division-by-zero would be handled.

Knowing programmers, I worry that people will write dummy catch
clauses that only serve to sweep the exception under the rug.

> 2) Since exceptions accumulate towards the root, it's common to have a 
>    way of summarising a set of exceptions.  Usually, this is done using
>    some notion of inheritance so that numeric overflow, division by zero,
>    etc might be summarized as 'ArithmeticError'.

Doesn't this lose information?  I can see why it is useful to *catch*
larger classes of error, in particular high up when you only deal with
it in a generalized way (e.g. reporting the error to the user), but
isn't it also useful to know exactly the kinds of error that can
occur? 

-ketil
-- 
If I haven't seen further, it is by standing in the footprints of giants