Proposal: Extensible exceptions
Henning Thielemann
lemming at henning-thielemann.de
Mon Jul 7 06:56:44 EDT 2008
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.
More information about the Libraries
mailing list