Proposal: Extensible exceptions

[Henning Thielemann]

On Sun, 6 Jul 2008, Yitzchak Gale wrote:

> I am now opposed to this proposal as it stands,
> due to code breakage.

If the proposal breaks code, then it should be implemented in new modules.
The opportunity could also be used to correct design flaws, that are in 
the current IO modules. E.g. there should be strict and lazy readFile:
   readFileStrict :: ErrorT IO IOError [Word8]
   readFileLazy   :: IO ([Word8], Maybe IOError)

  Then there should be new modules that strictly separate between error 
handling (they should be located under Debug) and exception handling (they 
should be under Control.Monad). Exception handling should be done with an 
ErrorT monad transformer (only renamed) which uses a type isomorphic to 
Either but distinct from it. This way exception handling can be used for 
all monads, not only IO. The great thing is, that this is even everything 
Haskell 98!
  This should be implemented on top of existing IO, but the new function 
should assert not to use the exception facility of IO, but only use ErrorT 
exceptions. It should be in a separate package which can be installed from 
Hackage, so people can play with it and improve it.

>> It might even be possible to get rid of the Error class and use the
>> Exception class instead.
>
> I like that idea. In practice, I always find strMsg and noMsg nothing
> more than an annoyance. What is really needed is a required Show
> instance, like the Exception class has.

What is it intended for? Exceptions must be reported to the user in many 
cases. 'Show' is reserved for emitting Haskell code, but that's not of 
interest for application users. A widely adopted class for generating user 
friendly, maybe pretty printed, text, does not exist so far. Application 
users are even interested in localised messages. So there should be a 
class which generates localised messages for exceptions.

> o For 6.10, make the new Exceptions available so that
>  everyone can start working on switching, but leave old
>  Exceptions as the default so that existing programs still
>  work. Prominently mark old exceptions as deprecated
>  in all documentation.

Please wait a bit even with deprecation. In 6.10 the new exception modules 
will still be in flow, one should not urge users to skip to this 
construction site. If the advantages become obvious programmers will skip 
automatically.

I would not remove the current modules for a long time. Module interfaces 
are never perfect. There will be new type extensions which allow for even 
nicer function types, and then you want to replace all IO modules, again. 
It's better to start a naming scheme which is open for future extensions 
and replacements.