Checked exceptions

Of late, as I've started reading blogs, I've seen a number of discussions on checked v/s unchecked exceptions, including in the context of C# v/s Java. Some well known people thinking Java, such as Bruce Eckel, also think checked excptions bring more trouble than they are worth.

Yesterday I was talking to my new colleague who comes from Microsoft, and he pointed me to an interview with Anders Hejlsberg, who created the C# language. Here he talks about why they chose not to include checked exceptions in C#. A number of other major arguments are similar. ( I'm too lazy to go back and find the links to all of them, so believe me, or search yourself :-) ). Here is a summary of my understanding of the argument, which is essentially a practical rather than conceptual argument:

• As you move up the hierarchy of methods in an app, or if you are building a huge system, the number of checked exceptions you need to catch keep increasing.
• You don't care about most of these exceptions.
• As a result, writing catch blocks for each of them irritates one no end.
• Therefore, most people just write

catch(Exception e){
\\ error handling
}
with the intent to come back later, which never happens.

• Therefore, checked exceptions serve little useful purpose, hence they should go.

If that's really a correct summary, (which I hope it is not), then I don't think I need to state where they are wrong. But let me do it anyway:

• If it's a feature that most people ignore, that doesn't mean it is not useful. Without the feature, those people won't do a better job of handling exceptions. With the feature, at least some people are doing a good job. Even they will not be able to do a good job with unchecked exceptions.
  
• If your methods are throwing a large number of exceptions, and/or you catch them with the block above, you are doing sloppy programming. Sloppy programming can't be used as a reason against a feature. ( Yes, it can be used as an argument to try and improve that feature.) Moreover, if your programmers are sloppy, they will probably do a worse job without checked exceptions.
• If people won't use exceptions properly, which the compiler partly forces them to, they certainly won't document their code properly, which is the only thing you can rely on when you don't have checked exceptions.

Having said that, the point about the empty catch block is one that I can identify with - have seen lots of people do that. But I think the solution is rather simple, although one that cannot be enforced by the compiler:

• for your application, create two base exceptions: MyAppApplicationException as a checked exception, and MyAppSystemException as an unchecked exception.
• subclass MyAppApplicationException when you have a new handlable error situation.
• subclass, or use MyAppSystemException when you have a new non-handlable error situation. Also use it to abstract out all lower level system exceptions.
• Client code: catch the specific instances of MyAppApplicationException that you can handle, and then, if there are any more, catch MyAppApplicationException. These two together mean that you catch only those that you care about, and can ignore the rest.
• Enforce this through the use of automated and manual code reviews.

Another argument Anders used is that checked exceptions break versionability - that is, if I need to add an Exception in a later version of my API, then I will break backwards compatibility.
I'm a much lesser programmer than Anders, so I'd take it as given, except that I don't see his point at all. Checked exceptions are part of your method signature, because they are part of your contract with client code. If you come across a need to add or remove a checked exception, you are altering behavior of your method. How is that conceptually different from adding or removing a parameter?
Let's assume for a second that there might be situations where you can alter the Exception list without altering behavior. You are probably doing it based on complaints from your users, so they will probably need the change anyway. Of course, they will need to modify code, but that would be for a real pressing need, right?
Even if you do need to add Exceptions that should not require changing client code, using the BaseException approach allows you to do it: all client code only needs to always have caught the BaseException.

Assuming that we use the BaseException approach, are there still any problems with Checked Exceptions?