Now to step into the trenches: the ugliness is precisely because in actual practice, defensive coding in Java means that callers of an interface must guard against it throwing unchecked exceptions anyway — the caller also typically has a contract it must uphold. And as a practical matter, Elliotte’s article dealt with one rather contrived example — the caller controlled both the implementation of the interface and the data the interface is applied to. Real systems don’t have this luxury, making it impractical to use the techniques Elliotte outlined. A simple example is the simple callback interface. What are you going to do if the implementation does something that throws a RemoteException? Are you really going to make every such interface declare its own checked exception?

As for the crash-only software idea, the answer is yes, you do want a program or thread to shut down just because DNS lookup failed transiently, but not if the language is Java.

Crash-only software is an interesting idea to respond programs that have thoroughly wedged themselves due to programming errors. However that’s appropriate for algorithmic flaws inside a program. Robust programs don’t let themselves get into illegal states in the first place. Environmental problems such as I/O errors are completely expected and need to be dealt with without bringing down the application or even a thread. For instance, do you want a program or even a thread to shut down just because a DNS lookup failed transiently?

Elliotte keeps missing something: you can’t always have a method propagate an exception by declaring that it throws the exception. An obvious example is when the method implements an interface method that doesn’t throw the exception. The only way to get an exception propagated past the interface-method-doesn’t-throw-the-error is to wrap it inside a RuntimeException. That alone should convince people that checked exceptions are a flaw in the language.

(And please don’t argue that the interface method was badly specified — the interface can’t predict which checked exceptions will be thrown. And declaring the interface method to throw Exception is just hideous, and is an argument against checked exceptions.)

Robust code is all about dealing with errors, whatever the errors, checked or unchecked. In practice this means making sure that you release resources or maintain state — such code uses try/finally and hardly ever try/catch. In the vast majority of cases, the only code that cares about the actual exception is the outer most loop, and it only cares about the exception because it wants to log the exception. And there in lies the problem with checked exceptions. I will submit that the most important thing to do with an exception is to log it, and checked exceptions are all too often swallowed. You can argue that exceptions shouldn’t be swallowed, but just stating it won’t make it so.

I will close by adding that actually trying to deal with errors is so passe. Ever heard of crash-only software? You think telecom software is written in Java? Think again.

The point of checked exceptions is to prevent unpredictable environmental conditions from being ignored. The checked exceptions camp wants to force developers to acknowledge and deal with these unpreventable situations. We’ve learned from brutal experience that we cannot count on programmers to properly check for sporadic error conditions. We want to make it inconvenient and painful to ignore problems because that leads to robust software.

The unchecked exception camp basically says, “Trust Us. We’ll handle the problem anyway” but the reality is otherwise. The problems that checked exceptions indicate–file not found, network failures, etc.–must be handled in both cases, with or without checked exceptions. The code you write in both cases to properly handle the underlying problem is identical. The only reason to make an IOException a checked exception instead of a runtime exception is so that programmers are reminded to handle the problem. The only reason to make an IOException a runtime exception instead of a checked exception is so that programmers can ignore the problem and write failure-prone software.

However, I noticed that all people who said they were in one camp and switched to the other – they all switched in the same direction – from using checked exceptions to not using them. Have I missed something – has someone switched in the opposite direction?

Basically, (help me if I haven’t understood it correctly) the unchecked exception group says that it is not necessary to force every exception to be caught by its caller. They say it is enough to have a single spot somewhere high in the call hierarchy to catch all exceptions, regardless what type they are. Also, they can choose to catch any particular exception earlier if they want to.

The checked exception group say that the caller has to catch them. It is free to rethrow them if it doesn’t want to deal with them, but it still has to catch them.

So, the unchecked group has an alternative solution that they claim works. Can the unchecked group describe a situation where that solution does not work?

Cheers

Nice comments… we must begin with “an error is an error” in any language, waht can be done whe someone delete alll records in a table ? mmm … Maybe another confussion is that in Java some programmesr trend to use them as an business validation .. I mean, some one uses “throw exception” to inform that the password was wrong …..

Uses checked or unchecked exceptions don’t guarantee that you have a robust application .. we are human, we make mistake. Using cehcked exception tell us what we must not forget… but … I watched a lot of code with try{ … }catch(Exception e){ null; } (senior java, maybe a little tired) … trying to prevent to manage the error … It’s no nice, it is better let’s flows the real error.

I repeat we are not working with geniouses we work with real guys, with personal problems and another issues, our mission it’s to help them,,.. My position, I really hate to use checked exception … I repeat, an error is an error no way treat with them ..

I don’t know, how much experience has Harold with other language (C, ADA, Lips, Cobol) and building real applications?, where you must be “quick” and go live soon as posible, when you must fight wiht legacy code …. to use a checked exception and don’t forget to catch every error in the system could be a nightmare code ?? I think (with respect), Harol is a great theorical guy, who can teach and write great books..

With Respect.

SQLException is a checked exception because the SQL string is evaluated by the database server (or the JDBC driver), and different servers accept different dialects of SQL. Again, you can’t tell at compile time whether the exception will or will not occur. Therefore SQLException is properly a checked exception.

URISyntaxException is one Sun got wrong. It should be a runtime exception because it doesn’t depend on the environment in which it executes and it can be verified at compile time. Basically it’s a type of IllegalArgumentException like NumberFormatException. However, it isn’t. It’s a checked exception. That’s simply a mistake.

I am not so sure. If the Exception class is re-factored to become “unchecked”, the existing code (that now successfully compiles) should still continue to work in the same manner. It’s just that billions of lines of today’s code that are wasted on catching and re-throwing will become redundant (in those cases when the programmer is indeed trying to properly propagate a checked exception instead of mishandling it way before it reaches the place where it should and can be properly handled.)

Also, here’s the more accurate link to the article I mentioned in the previous post:
http://constv.blogspot.com/2009/08/error-handling-and-exceptions-in-java.html

http://constv.blogspot.com/

Hope that helps someone.