You may be interested in the discussion on this article at LtU: http://lambda.weblogs.com/

I think condemning checked exceptions as a whole is a mistake. Anders Hejlsberg very clearly explains the results you get when you make everything a checked exception. But I think it's more subtle then "checked exceptions are evil". There is a real use for checked exceptions. I quote Rod Johnsons book:

Question: Should all callers handle this problem? Is the exception essentially a second return value for the method?

Example: Spending limit exceeded in a processInvoice() method.

If 'yes': Use a checked exception and take advantage of Java's compile-time support.

Question: Will only a minority of callers want to handle this problem?

Example: JDO exceptions

If 'yes': Extend java.lang.RuntimeException. This leaves callers the choice of catching the exception but doesn't force them to.

Question: Did something go horribly wrong? Is the problem unrecoverable?

Example: A business method fails because it can't connect to the application database.

If 'yes': Extend java.lang.RuntimeException. I do think a java.lang.Error would be more suitable here. According to javadoc an Error signals a "abnormal condition that a reasonable application should not try to catch".

end of quote

groeten uit nederland
Joost

I can see two problems in not having checked exceptions.

1. How do you know that the method throws an exception that you are meant to handle. Especially when you write code that uses some toolkit than in turn uses someother toolkit.

I know that exceptions can be documented in C# but can you find the possible exceptions that may be thrown all the way down the call tree?.

2. It must seem to ecourage sloppy coding, in that to reduce try/catch noise one doesn't bother to include any and let the caller worry about it. Almost like the VB hell of "ON ERROR RESUME". Of course one can have sloppy code with checked exceptions and the loud noise that might come from try/catch proliferation.

As for versioning I'd have thought that if you change the signature/contract of a method then the caller has to defend against it instead of quietly ignoring the fact that the method may now fail because a new reason.

We only have to look at the amount of software outthere that complains using dialogs "Can't do xxx" then "Unable to ..".

Anders Hejlsberg wrote:
C# is basically silent on the checked exceptions issue. Once a better solution is known—and trust me we continue to think about it—we can go back and actually put something in place.

This proves to me that this guy is smart and cares about what he's doing. C++ exceptions were an experiment, and Java checked exceptions were an experiment too. Why do we want experimental features in a programming language? Let's have well-defined, thought-out features in our languages; they are not some designers' playground.

I think that proper (and improper) handling of exceptions will continue to be an issue until we get transactional semantics in our programming languages. How else do you guarantee that you recover properly when an exception is thrown? The problem is too hard to handle correctly otherwise.

How about having "unexpects" keyword ?

void methodNumberOne() throws ACheckedException {
...
}

void methodNumberTwo() unexpects ACheckedException {
...
methodNumberOne();
...
}

The compiler then compile methodNumberTwo() as like:

void methodNumberTwo() {
try {
...
methodNumberOne();
...
}
catch(ACheckedException e) {
throw new UnexpectedException(e);
}
}


Of course, UnexpectedException is a RuntimeException descendent. Is this a good idea ? This way you can explicitly declare what exceptions are unexpected and the code is totally unprepared for those situations.

The line of Heilsberg's argumentation seems to be the following: "many programmers misuse checked exceptions, so let's remove the language support for them altogether". What kind of logic is this? This simply means acknowleding the sorts of described "worst practices" and letting them spread further.

Complaining about method signatures becoming fatter because of too many checked exceptions? Think about why you are passing all those weird exception types on to your clients! Making your clients deal with exceptions that stem from implementation details of your module is a design error.

... Anders Hejlsberg point of view shows once again that microsoft just wants to make junior programmer being able to write bad code!

I wonder if he read the chapter about how to use the java exceptions handling mechanisms in Joshua Bloch's Effective Java Programming Language Guide.

Whether checked exceptions are useful or not depends on a more fundamental question: Useful for what?

If one's goal is to make a programming language popular for programmers (so that programmers start using it, and start to like it), then I agree that things should be kept simple - just don't cause many troubles for the programmer, just keep things simple and smooth. Then checked exceptions are more trouble than they're worth.

On the other hand, if one's goal is to build systems that can survive all kinds disasters and exceptional conditions without a blink, then checked exceptions are very useful, indeed. They're useful, because they give you a programmatic interface to failure. And that interface makes it possibly easier to recover from those failures.

Traditionally, the latter category of software contained things like operating systems, file systems, real-time systems, etc. For instance, it's hardly acceptable to just pop up a dialog box, "Sorry, disk sector XXX failed. Please reboot." Rather, you just want to hide that error from the user, and route around it. Indeed, disk controllers just handle such things themselves, mapping around bad disk sectors, without even letting an OS know about the problem. Traditionally, end-user applications are much less industrious: You can always pop up that message dialog and push exception handling up the chain to the user.

But the standards are changing, and end-user software will have to become as reliable and OSs, file systems, disks, or embedded systems. For instance, today it's still OK to pop up a dialog to the effect: "Can't save file. File system full." That may no longer be acceptable in a few years: People don't care about file systems, they just want the system to save their darn file (even if it means that the system now has to borrow another machine's file system perhaps).

As an increasing number of people use software, users' tolerance is going to diminish: They will demand software that can fix its own problems. In turn, they will demand that programmers actually consider the exceptional conditions AND write the software so it recovers from those exceptions.

This is already happening in the industry I am in. Displaying an error message "Cannot connect to database" might be acceptable in an environment that caters to programmers or system administrators. But displaying that message to end-users who don't know what a database is, or why you would have to "connect" to one, is going to be a serious problem. Such users lose patience very quickly, and dial the tech support line with great indignation: "Your system doesn't work. I'm losing money, I can't conduct business. Come out here right away, and fix this." They can't and won't follow instructions - they will want you to go out to their location and fix their problems, even if it means only a database reboot.

From a business point of view, that's going to be an extraordinarily unprofitable venture. So, instead, you probably want the program to declare that connection exception, and then think of all the ways your program can reconnect to that database, and create an exception handler that's activated by that connection exception. Or, if all fails, ship a log file back to your support office even BEFORE the customer notices the error (or at least before they call).

I like to declare only those exceptions where there is a reasonable chance of automated recovery. But once I declare those exceptions, that says, in essence, that the corresponding recovery routines are now a system requirement - the system doesn't meet its requirements without them.

I do agree that declaring exceptions from which automated recovery is hardly possible, is an undue burden, and such a practice completely obliterates the value of checked exceptions: It simply invites programmers to leave empty catch clauses in their code.

In summary, as the standard for software quality rises, checked exceptions will continue to play an important role in making software more robust and reliable. They can be an inmune system to software. And an abused immune system is just as bad as an organism without one altogether.

Anders Hejlsberg says: The scalability issue is somewhat related to the versionability issue. In the small, checked exceptions are very enticing. With a little example, you can show that you've actually checked that you caught the FileNotFoundException, and isn't that great? Well, that's fine when you're just calling one API. The trouble begins when you start building big systems where you're talking to four or five different subsystems. Each subsystem throws four to ten exceptions. Now, each time you walk up the ladder of aggregation, you have this exponential hierarchy below you of exceptions you have to deal with. You end up having to declare 40 exceptions that you might throw. And once you aggregate that with another subsystem you've got 80 exceptions in your throws clause. It just balloons out of control.

We'd encountered situations like this in an RMI project.

We faced some of the issues Anders mentions with using checked exceptions and so we made a conscious decision to define a hierarchy of unchecked exceptions for the application. This is not to say we discarded checked exceptions altogether, we just used them as we saw fit.

We also needed to handle checked exceptions from the server side that were not application related. So we designed a wrapper for the parts that talked to the server that translated the non-application exceptions to application (mostly) unchecked exceptions. Yes, we did lose some information in the process but we moved ahead.

This way, we were able to achieve a reasonable balance.

Overall, you do run into some problems with checked exceptions and some other without, but wouldn't checked vs. unchecked be a matter of design decisions?

Take the following code as an example:

Connection conn = null;
PreparedStatement stat = null;
ResultSet rs = null;
try {
  conn = DbHelper.getConnection();
  stat = conn.prepareStatement("SELECT * FROM addressbook");
  rs = stat.executeQuery();
  while(rs.next()){
    // print out name & email
    System.out.println("Name: " + rs.getString("name"));
    System.out.println("Email: " + rs.getString("email"));
  }
} finally {
  if (rs != null) rs.close();
  if (stat != null) stat.close();
  if (conn != null) conn.close();
}

All the database calls can result in a SQLException which are checked exceptions. At production time, this code should only fail if the database connection is lost or the database crashes. As a result of SQLException being a checked exception the above method will either have to declare to throw SQLException or wrap SQLException (which is most likely the better design choice).

So the problem with checked exceptions is that it forces the library user to handle the exception even if this isn't required. In the above code, we should not be catching exceptions from the query execution and result set retrieval since exceptions from these calls will most likely be from a coding error. Note however, part of this problem is due to lack of exception hierarchy for SQL exceptions.

Anyway, I still think checked exceptions are useful but they must be used with care. This is the problem with checked exceptions. They cause problems for the API user if they have been used where they should not have.

I think a good start for determining wether to use unchecked or checked would be Rod Johnson's rules in Chapter 4 of "Expert One-on-One: J2EE Design and Development" which you can get from http://www.wrox.com/books/sample-chapters/samplechapter_0764543857.pdf

> Adding a new exception to a throws clause in a new
> version breaks client code. It's like adding a
> method to an interface.

Exactly! This is what you want to happen. If you think it's important enough to be part of the contract (in the throws clause of your API), then you want client code to break. If not, throw a RuntimeException.

I haven't decided exactly where I fall in the checked/unchecked exception debate, but I can't fully agree with the versioning issue presented here.

Anders says that if an interface is changed to add a new exception then all existing clients are broken. The argument is that most clients aren't actually handling the exceptions anyway, they're letting them get handled farther up the stack.

In general a component or subsystem that can throw many different exceptions should provide a base exception class. Methods that wish to defer handling of exceptions can then add "throws SomeBaseException" and accomplish two things: deal with any current and future subtypes of SomeBaseException; and make it explicit that this method does not try to handle that set of exceptions. Methods that *do* need to deal with one or more of the possible exceptions can catch the ones needed (and still declare "throws SomeBaseException", if that's the desired behaviour).

On the other hand, we've all seen lots of code with "throws exception" and those empty catch clauses. This does suggest a problem with the feature. Rather than discarding it altogther, perhaps there's some way to encourage users to use it properly?

>"Adding a new exception to a throws clause in a new version breaks client code. "

Adding a new exception to a throws clause doe NOT break client code(does not
break binary compatibility).Its embarrassing that the interviewers/tech editors
did not catch this.

>"You don't want a program where in 100 different places you handle exceptions and pop up error dialogs. "
..."The exception handling should be centralized,"

Refactorings/Design patterns can be used centralize exception handling.See:
<a href="http://www.refactoring.com/catalog/extractMethod.html">Extract Method</a>
or even use <a
href="http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpattern s.html">Simple Singleton</a> if you must.


>"...people do ridiculous things. For example, they decorate every method with, "throws Exception...
[OR]...You end up having to declare 40 exceptions that you might throw. "
Forty exceptions in a throws clause? This interview is sounds more like a troll.

"I can't tell you how many times I've seen this—they say, try, da da, catch curly curly."

I have seen empty catch blocks in poorly written overly verbose intro to Java books.
Where have you seen such awful code?


Checked exceptions are one of the reasons why Java is better than C# -
<a href="http://www.freeroller.net/page/ceperez/20030129?catname=101%20List">Re ason
#64</a> Would rather rely on documentation than have the compiler let you know of a possible exception?

"For example, lots of newbie's coming in from the C world complain about exceptions and the fact that they have to put exception handling all over the place - they want to just write their code. But that's stupid: most C code never checks return codes and so it tends to be very fragile. If you want to build something really robust, you need to pay attention to things that can go wrong and most folks don't in the C world because it's just to damn hard.
One of the design principles behind Java is that I don't care much about how long it takes to slap together something that kinda works. The real measure is how long it takes to write something solid. Lots have studies have been done on developer productivity, and Java beats C and C++ by a factor of 2...."
- <a href="http://weblogs.java.net/jag/">James Gosling</a>


I'm a strong believer that if you don't have anything right to say, or anything that
moves the art forward, then you'd better just be completely silent

Here Here!!

Hello! Have we forgotton about semantic distances? I think anyone who suggests increasing it, should read The "Pragmatic Programmer: From journeyman to Master" or similar book.

A error that is not handled where it occurs, is often not handled at all. This is especially true for programmers with a sloppy style of their art. Sloppy programmers, resistant to learning how to do it right, won't do error handling properly anyway.

If exceptions are not handled locally, how does the main message loop get to know how to deal with exceptions, especially in the large systems case. A FileNotFound Exception might be innocent or it disastrous. Should the main message loop inspect the stack trace, and decide what to do?

What if a subsystem is poorly implemented, (where throwing it out is not an option). Such subsystems act as snipers, and in programming languages without checked exceptions you will not have good chances to discover what errors/exceptions might be thrown before they blow up in your face production time.
Systems with local try - catch curly curly, should not be reused at all: they will never behave in a larger perspective. This is bad bad programming, and is not worth struggling with.

After reading this article I can't help but wonder why you didn't state that checked exceptions are optional in Java? It is up the coder to decide if they want checked or unchecked Exceptions. If you extend RuntimeException it is automatically unchecked. For example, how many times have us Java coders had to deal with NullPointerExceptions, but never actually had to put a catch block in our code? It's just one example of an unchecked exception in Java. Granted, there are several checked exceptions in Java that you are required to deal with if you wish to use that Object, but the designer of that Object thought it necessary to deal with that exception. If you don't like it, create your own Object that does the same thing and use unchecked exceptions.

As for this debate in general, I think it's laziness that makes people disagree with checked exceptions as a whole. They are an amazing feature and quite useful to a good programmer. I realize they are often abused, but that's the problem of bad coding rather than bad language implementation.

Thanks,

Matthew Hicks
darkfrog@pyramex.com