Your example is of a poorly implemented "interface" and the poor use of checked exceptions. However, I've not heard one respectable reason against the *concept* of checked exceptions (their misuse doesn't count as one).

Dan

My understanding of the "fragility" of method signature in respect to checked exceptions is that, too often, developers merely rethrow contained exceptions, creating a large list of exceptions (in the throws clause) tacked to the method signatures.

Again, from what I've seen (the the two articles you pointed out are no exceptions...no pun intended), the issues surrounding the fundamental problem with checked exceptions has more to do with how developers deal with them, and not the concept, itself.

For example, the fragility issue should be solved by properly catching exceptions and rethrowing the proper one(s) for the given layer. If development is approached via layers, then each layer should have its own exception hierarchy. This keeps the number of exceptions thrown to a minimum (usually just one).

Bruce complains about code readability and how developers misuse them. My problem with that is that I think they were added to the language for a purpose, and that for developers to ignore them (or treat them improperly) is to make for bad development. So, it's not a problem with checked exceptions, themselves, as it is a problem with training developers to think differently about how they code. Just as test-first coding requires a different mindset, the user of checked exceptions requires the developer to approach development with a particular mindset. More specifically, a high percentage of code exists to handle error conditions (in whatever form). If a developer approaches development is the attitude of "just get the job done," then they'll take shortcuts (some of which will be the misuse of checked exceptions). However, if they approach development with the opinion that there be no holes, and that error handling is a significant part of what they do (just as testing, etc. should be), then checked exception won't get in the way. In fact, they'll help (because the compiler will help them be honest).

Most of the real complaints I've heard are either based upon developers misusing them, and because many libraries and API's don't use them appropriatly (especially the way the Java libraries are...which is admittedly painful).

Of course, I'm not one to say that everything should be a checked exception, either. Unchecked exceptions are important, though I was surprised that Alan Giffiths main thought on them was programmer error. There are two sets of "exceptions" that are non-checked in java: runtime exceptions and errors. One is for programmer errors (runtime exception). Errors are for situations where your app probably can't handle it, such as out of memory errors.

Regardless, I think they both should be used appropriately, but I don't think that checked exceptions are inherently "bad," though they are certainly misused too much (just like C pointers, inheritance, etc.).

Dan

I'm not sure why you think that's "bad." I'm assuming it's because, since your implementation of the interface doesn't actually throw the exception, that it would be nice to not have to declare it. However, the client of that interface should view your implemetation as just that interface, in which case, the designer of the interface made the decision that it should be part of the signature (whether they were correct or not is another thing).

In other words, a checked exception in a signature helps define that method, regardless of whether it's used or not (just like parameters can be ignored, but are still there). My point is that it may be the poor design of the interface, or it may be that the designer wanted the user of that interface to be aware (and effectively force them to handle the interface a certain way). I don't see it as a problem with the concept of checked exceptions, though.

Dan

I think 10 times is a little excessive. And I think the database access (specifically SQLException) is also a poor example, as it's debatable whether it should have been a checked exception in the first place.

Dan

Unfortunately, it does not. The assumption that just because something is misused, that it is somehow intrinsically (sp?) wrong is not a strong enough argument. That does not mean, however, that misuse doesn't point in that direction. It's just not enough to prove. So, I agree that it requires a closer analysis, but I don't agree that it necessarily provides proof.

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