Proposal: Extensible exceptions

[Yitzchak Gale]

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

However, the proposal is nice, and I think that we
could get there via a more friendly path.

Discussion and suggestions follow.

I wrote:
>> How does this affect integration between IO exceptions
>> and pure exceptions, in particular Control.Monad.Error from mtl?

Ian Lynagh wrote:
> I don't think anything needs to change, but it might be desirable to use
> a similar sort of extensible-errors.

No, the Error class is already extensible. But Exception members
are not suitable, since they do not have strMsg and noMsg
methods.

With the old Exceptions, that was not too bad - you just need
to wrap the single Exception data type.

This proposed change makes things much messier, and it will
break code.

> 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. And of course, having all
Exception instances available as candidates for pure exceptions
is nice.

But this would be a traumatic change. There would need to be some
migration/deprecation path.

As Bulat points out, there will be a lot of pain caused even
for Exception itself. The fact that it is easy to figure out
how to fix code to make it work again (assuming that is true)
will not change the fact that many, many programs will
no longer compile. Past experience shows that this
causes a lot of damage.

To get there with less pain, I think we should:

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.

o In the next version, make the new Exceptions the default.
  Make sure that programs using new Exceptions for 6.10
  will still work (e.g., leave NewException as an alias for
  Exception, or whatever).

In parallel, do something similar for deprecating the mtl
Error class and using Exception instead.

As a general note - it has been suggested several times
that we need a facility like Python's "from future import ...".
That would be much better than making up names like
"OldException" and "NewException" every time.

Though in Python itself, that facility only applies to the
core language, not to libraries. When an important library
is changed in an incompatible way, they tend to use a
new name for the new library and leave the deprecated
library around with its old name for years and years.
We could also do that here.

Another approach would be to build this kind of
facility into the package system.

Thanks,
Yitz