Lambda the Ultimate

(For convenience I'll limit myself exclusively to talking about checked exceptions unless explicitly noted.)

Dislaimer: My practical experience is limited to Java 1.4.x (the horror!) -- so things may have changed.

The fundamental problem with checked exceptions is that the declared exceptions of a method are contravariant while inheritance is covariant. (Or the other way round, I always forget which is which ;)). By the way, this is also an issue for the design of closures for Java, as you can probably tell from the example below.

The issue arises frequently in API design, let's say you want a functional-ish API for collections:

    interface Filter {
              public boolean transform(Object x);
    }

    interface Collection {
        public void filter(Filter t);
    }

    class List implements Collection {
          public List filter(Filter t) {
             // Just imagine a trivial implementation here.
          }
    }

If you now try to write a filter

    class FilterByDatabaseLookup {
          public boolean transform(Object x_) {
                 Long x = (Long) x_;       // Generics (Java 1.5) at least fix this ;)

                 // Obtain DB connection
                 ...
                 // Look up x in table XS
                 ...
                 // If x exists in table XS, return true, otherwise return false
                 ...
          }
    }

The problem with this is that it's highly unlikely to compile, because almost all DB access methods throw JDBCException (or whatever). As far as I know the only workaround is this:

    class FilterByDatabaseLookup {
          public boolean transform(Object x_) {
                 Long x = (Long) x_;       // Generics (Java 1.5) at least fix this ;)

                 try {
                     // Obtain DB connection
                     ...
                     // Look up x in table XS
                     ...
                     // If x exists in table XS, return true, otherwise return false
                     ...
                 } catch (JDBCException e) {
                     // We can't really do anything at this point, so we need to punt.
                     throw new RuntimeException(e);
                 }
          }
    }

The workaround also means that you really can't know what's being thrown in any particular block because you're sometimes disguising JDBCExceptions as RuntimeExceptions. Also, if you really want to catch that JDBCException in some outer code, you're now forced to use the rather non-idiomatic

        try {
           // Do whatever with a List.filter using a FilterByDatabaseLookup
        } catch (RuntimeException e) {
          if (e.getCause() instanceof JDBCException) {
             // Do whatever.
          } else {
             throw e; // Re-throw
          }
        }

I know this little example may look trivial, but in a codebase of any respectable size this particular issue with exceptions is a huge pain in the rear. The more different APIs you have to combine to solve your problem the worse it gets.

In some of the projects I'm working on, there are huge swaths of code just to deal with exception "conversion" such as above. Code which is worse than useless since it provides no function, but can lead to errors if you're not careful.

The only real solution I've seen for this issue is to do away with checked exceptions completely. The only examples I've seen which attempt to justify the existence of checked exceptions are trivial ones.

(Above may contain serious errors of thinking since I'm sick and have a massive headache.)

I believe, instead, that the point of checked exceptions is to urge the programmer to deal with problems in a controlled and task-appropriate manner, rather than sticking their heads in the sand.

Applying this to your example, I suggest that the key (no pun intended) is that your example FilterByDatabaseLookup#transform must be viewed as a (potentially) partial function; it is the programmer's responsibility to consider as part of the design what it means to be unable to answer true or false for a particular argument. More precisely, FilterByDatabaseLookup#transform actually wraps a partial function (the database lookup), and the determination of what to do if that lookup returns bottom (throws an exception) is a context-sensitive design issue.

To extend the example, if I'm filtering a list of membership IDs based on whether the membership is still current (not yet due for renewal), I have three cases:

1. Assume true: If I'm filtering a list of members to decide which ones should get an invitation to an organizational event, perhaps I want to give the benefit of the doubt in case of inability to determine current status, and include that the member for invitation. Here I'm assuming that the consequences of an incorrect assumption (erroneous inclusion of a member) are small.
2. Assume false: If I'm filtering the list to see which ones should be sent a renewal reminder, perhaps I want to avoid wasting postage (or raising concern) by not dunning members unless the d/b confirms that they are due for renewal. Here again, I assume other processes (e.g. repeat renewal notices, etc.) that make the consequences of an error acceptable.
3. Assume bottom: If I'm filtering the list for some security-critical purpose where the entire result must be correct with high reliability (make up your own case, ranging from secret ballots to a query from Homeland Security ;-), I may want to treat a database exception on a single ID as invalidating the entire resulting list, by throwing a FilterPredicateFailedException to the layer of code that is expecting the filtered list. In this case, the consequences of a single-element error are unacceptable.

I believe that the only real solution for this issue is to consider what failure to be able to answer at the element level means about the usability of the entire resulting list, and design accordingly. Assume inclusion (risking a false positive), assume exclusion (risking a false negative), or fail the entire filtering operation -- each of these is reasonable for some scenarios.

One of my collegues is fond of saying that 80% of all production code should be about error handling. We would certainly be dissatisfied with a compiler that treated all errors by simply responding "You messed up somewhere" and crashing. We expect precise identification of the location and nature of the error, and really like it when the compiler is robust enough to make a reasonable adjustment and keep working. (How many of us have yelled at a compiler, "If you knew I needed a comma there, why didn't you put it in for me and keep working?")

Likewise, I believe that production-quality software should be concerned with precision and context-appropriate response to errors that occur in its own domain.

The only real solution I've seen for this issue is to do away with checked exceptions completely.

Checked exceptions aren't inherently evil, just poorly implemented in Java. If another language ever takes up the idea then the designer would be well advised to look at the latest research in other effects systems. A few ideas

1) Make exception declarations polymorphic ("generic" in Java terms). That neatly solves the problem above. In my example I stick to the overly verbose way of creating higher order functions in Java, and use an in-place imperative version of filter instead of a functional one so the examples can be compared side by side. Also I use square brackets so I don't have to mess with HTML entities.

    interface Filter[T,E] {
              public boolean transform(T x) throws E;
    }

    interface Collection {
        public void filter[T,E](Filter[T,E] f) throws E;
    }

So now xs.filter(f) throws whatever exception f throws

    class FilterByDatabaseLookup extends Filter[Long, JDBCException] {
          public boolean transform(Long x) throws JDBCException {
             // do whatever, the database exception is declared
          }
    }

Of course, there needs to be a way to create a union type of exceptions for that to work.

2) Infer the throws clause, at least for implementations. I hate repeating myself. Make the tools do the leg work, not me. (While we're at it, infer everything else, and figure out a way to recognize the forAll on type parameters so I don't have to declare them - see ML and Haskell).

3) With exception inference, add a wontThrow clause. If I declare that a certain method won't throw IOException and the inferencer can't prove it won't then I have to handle it somehow.

Thank you all for your comments. I am slightly surprised all reactions touch only checked vs. unchecked exception topic. I'd expect there is more to say about exceptions, but still your takes on checked exceptions are really interesting, so I guess this is OK.

I really like the explanation of partial function. I have to agree that in case an API deals with partial functions and the partial function result can influence the return values, it seems more appropriate to use checked exceptions. However this leads to my favorite topic of "correctness vs. empiristic programming" - it is correct, right and elegant to define partial functions with checked exceptions, however if we define them with unchecked ones, they will be easier to use, at least in most common cases. The use will not be fully correct, but in the world where the most important thing is time-to-market, this does not that important to majority of users.

I seem to like the idea of generification of exceptions too. Is not this another example of co-variation and contra-variation? In case one is offering an API for providers, e.g. interfaces that others can implement it is good idea to give them wider choice of which exception (if any) they want to throw. In case one is offering a client API (which others can call), it is desirable to throw as little exceptions as possible. However, if one provides both types of API (like in the Filter example above), the best variety of API user choices is obtained, if the exception remains parametrizable until used, e.g.: E extends Throwable.

I also understand the pain when converting one checked exception to another and the desire to have Maybe a type. On the other hand it seems to me that this would trivially be satisfied if we all decided that the right checked exception is IOException and subclasses. Methods returning Maybe a values could then throw IOException while those returning a would throw nothing. This seems to have at least the same expressiveness as the Maybe a case, does it not?

Thanks for sharing your thoughts with me. I'll convert them to a topic on apidesign.org wiki, when I find some time.