Alastair Reid
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