Proposal: Extensible exceptions

[Daniel Yokomizo]

On Mon, Jul 7, 2008 at 9:02 AM, Johan Tibell <johan.tibell at gmail.com> wrote:
> On Sun, Jul 6, 2008 at 10:13 PM, Henning Thielemann
> <lemming at henning-thielemann.de> wrote:
>>  In Modula-3 you have to add the exceptions that can be raised to a
>> PROCEDURE header. Java has adopted this mechanism.
>
> Many people argue that this was a mistake [1, 2, 3, 4]. For one it
> requires that you rewrap exceptions at every abstraction boundary or
> expose your implementation details in the API. For example, imagine
> that you decide to use an SQL database as a data store and declare
> that your functions throw an SQLException. If you later change your
> mind and want to use a plain file for storage you need to change your
> function's type and thereby break clients that use your API. If you
> don't want this to happen you have to wrap all exception in
> MyException and throw that.

In Java it was a mistake, but only because their type system sucks (I
program in Java in my day job). There was no way to create a generic
(i.e. using Java terminology) class that had the option to throw
exceptions prior to 1.5 and even then it was just a hack:

interface Foo<E extends Throwable> {
    public int foo() throws E;
}

We can implement Foo<IOException> and Foo<RuntimeException> but if the
implementation throws two distinct exceptions we must use the common
superclass of both, because we can't write Foo<A | B>.

Exceptions as part of the types are a good idea but can become problematic:

(.) :: (b -> c throws x) -> (a -> b throws y) -> (a -> c throws x + y)

This kind of signature is the only correct way to express this without
losing information, but it requires some way to encode the typed union
without creating too complicated types.

Going back to Java, it is problematic to convert exceptions to
abstract the implementation, there's no easy way to provide combinator
to do that, but in Haskell this is much easier so I don't think it
would be as painful as it is in Java.

> 1. http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html
> 2. http://www.mindview.net/Etc/Discussions/CheckedExceptions
> 3. http://www.ibm.com/developerworks/java/library/j-jtp05254.html
> 4. http://www.oreillynet.com/onjava/blog/2004/09/avoiding_checked_exceptions.html
>
> Cheers,
>
> Johan

Best regards,
Daniel Yokomizo.