Since there are several separate threads (that is, responses to response) within this, it's going to get tedious responded to each and every one of them separately, so, if it's okay with everyone, I'll try to pull my responses down this direction to try to keep things a little clearer and cleaner...

First of all...I have no issue with agreeing to disagree. My experience has been my own, and I've found checked exceptions helpful. I've also seen them misused, etc. I think that they can aid developers when used appropriately. And yes, they become a pain when not used appropriately. Part of my perspective is probably tainted by years of experience working with Java (I used to do C/C++, but it's been a while).

Having said that, let me see if I can restate and handle most of the objections as best I can (and I fully admit to being unable to clearly express my opinion, but I'll do my best).

Interfaces: I actually think that using checked exceptions in interfaces is a good thing (within reason, of course). Why? Because I perceive an interface (a Java interface) to dictate a particular role for a class (that implements it). The interface defines certain signatures, which have a return type, method name, and parameters. I think checked exception make a welcome addition to it (that doesn't mean that all interfaces should have checked exceptions defined...only if it makes sense). I don't think that it makes the interface fragile. In fact, as crazy as it sounds (and I'm sure it sounds crazy), I have no problem with an interface defining an exception when some of the implementations of it may not actually thrown the exception. Why? Because that's part of the signature, and as a user (from an API perspective) of that interface (not as the implementor), I make certain assumptions about the method (including any checked exceptions). It's more information (even if it's the wrong info). It tells me that I should beware of the particular method, as it *may* throw that exception (even if a particular implementation will never do so). I realize that that flies in the face of what many of you consider good, but my reasoning for it is one of trust and information. I want to know what I'm getting into with a particular interface, and I trust that the designer/developer of it has written it such that I, as the user (from an API perspective), view it as it was meant to be (an method returning a particular value, taking certain parameters, and potentially throwing certain exceptions).

Misuse: though I agree that they get misused, I don't think it's appropriate to discount it as much as it's necesary to educate. There are many language tools that get missused, such as inheritance, etc. I think any developer who freely ignores return code is the same one who will freely ignore checked exceptions, and who is the same one who will not use unchecked exceptions appropriately, either. In that case, checked exceptions are no more valuable than return codes, except for one difference: in order to ignore checked exceptions, the developer has had to go out of their way to ignore them (they had to either rethrow it or catch and ignore). In that way, they are a little better.

Back in my C/C++ days, it was common to see code like this:

funcBar(...)
{
doA(...)
doB(...)
doC(...)

return foo;
}

with each doX() method returning something (zero if successful). With exceptions (checked or unchecked), the assumption is that those methods will perform just fine (assumed success) unless an exception is thrown, in which case, a catch clause somewhere up the stack will stop and do something interesting.

The problem is the checked exception tends to make the developer deal with an unsuccessful call too soon. In some scenarios, this becomes a pain, because the exception should be dealt with at a high enough place in the stack to be interesting. For those situations, it makes sense to wrap it in an unchecked exception and rethrow. However, in other situations, it makes sense to deal with the exception sooner, if for no other reason that to put a pretty error on the exception at the point where enough context is known to do so. The real question is whether it's appropriate to *force* someone to deal with that exception sooner, rather than later.

So, ultimately, I think it's a question of perspective. From a user of an API's perspective, it's common to complain about checked exceptions. From a designer of an API, it's common to want to dictate as much as possible, in order to give as much information to the user as possible. My perspective is, it's easier to produce safer code when the compiler helps the designer to dictate the way in which an API is used. Hence, the layered approach lends itself to checked exceptions because each layer (and I'm talking high-level layers here, not individual methods in a stack trace) can be independent from the next.

Again, I think it's a question of a tool to use to help. Unfortunately, it's been misused enough to cause a backlash. And in some cases, rightly so, since many libraries have not designed their exception handling well.

Dan

As I was writing that phrase about more information being good, regardless of it being wrong kind of struck me as a really poor way of explaining things. On the surface, I would completely agree with you.

It makes some sense that, given an interface (with defined checked exceptions) with a particular implementation not throwing said exceptions, that the interface is considered "wrong" because an implementation doesn't actually implement it (that is, it doesn't have the possibility of throwing an exception, so it could be said that the interface isn't truly implemented properly....it's "wrong").

However, that's not how I looked at it (though that appears to be how I said it, which is obviously my fault). The way I looked at it was that the interface defines a particular set of signatures (for our purposes, one is enough). For that particular signature, it defines three basic things: the return type, the parameters, and a checked exception (I know, there are other things in there, such as the ordering and types of parameters, etc...just trying to keep things simple). The checked exception means (as I look at it) that the method *may* throw an exception of that type. That means that it may not. In fact, I *hope* that it doesn't, but I code such that it might.

Because I trust the signature (the compiler says I can), I assume that it's possible. The checked exception gives me additional information in that it's a *hint* that a particular exception *may* (and *can*) be thrown. It doesn't state that it *must* or that it *will* under any given circumstances. In that case, it's additional information that isn't necessarily *wrong* if a particular implementation doesn't actually throw the said exception. It comes back to perception, I guess.

If we change the example so that it was an unchecked exception, instead, would that change anything? First off, I would *hope* and assume that the interface was well enough documented that it would indicate that an unchecked exception might be thrown under certain situations (something like: this method may throw this exception....). If not, then I would not have a lot of trust in that interface as I'd probably get exceptions thrown and not know that I was to catch them (this isn't a question of *where*, but the need to know that it can so that I can make the decision as to where).

Given that it's well documented, what about an implementation of that interface that didn't throw the exception? Depending upon how I use that interface, I may not know that a particular implementation doesn't throw the exception? Why? Because the construction of the implementation may be hidden from me, so I may not even know what class I'm actually using (that's the whole point of using an interface, after all). So, I would handle the situation identically, regardless of whether there was a checked or unchecked exception (granted that there may be slight differences in the syntax, since I have more flexibility as to where I deal with the unchecked exception, but I also have better inherent documentation with the checked one...it's a trade-off, to a certain extent).

As for a good example of a checked exception...

Since most of my current experience is with web-based apps, I'll use a fairly simple example: a Struts-based web app.

I create a business object layer that handles the business logic (and, somewhere in there, persistence). That layer defines some interfaces and concrete classes that the presentation layer interfaces with. Where appropriate, the business layer throws a standard application exception (with possibly a couple sub-classes if necessary). In the presentation layer (say, the struts action class), calls are made into the business layer. Since I, as the business layer writer, provide a single exception layer to the presentation layer, it can easily have code that does something like this:

try
{
...get data from user or whatever.
callBusinessLayerA(...);
callBusinessLayerB(...);
...use data from business layer to setup view or whatever.
}
catch ( ApplicationException e )
{
..set up error messages to display error from business layer...
}

Obviously, I'm leaving out lots of details, but the idea is that the presentation layer only deals with one (or only a very small number) application layer.

Of course, this can just as easily be done using unchecked exceptions. The difference is one of safety. As the writer of the business layer, I'm forcing the presentation layer developer to deal with my exceptions. If he merely ignores them (nothing in the catch), then hopefully, that'll get caught in testing or code review. In fact, it's fairly easy to write up a tool to automatically find those kinds of bugs (there are probably tools out there that do it, in fact).

I realize that it's a fairly simple example, but the idea of layering the exceptions simplifies things considerably. When dealing with junior to mid-level developers, I like the additional safety (try working at places like EDS or Accenture where the developers are not trained or taught...having extra checks like this are really helpful).

Dan