Because a huge proportion of the time there's nothing useful that you can actually do when you catch an exception, other than print the stack trace and exit. And because people are forced to catch the exception instead of letting it bubble up and stop the program, half the time they just swallow it and ignore it, which is even worse.

A decent roundup of some of the arguments for and against: http://www.ibm.com/developerworks/java/library/j-jtp05254/in...

It often leads people to write code like this:

    try {
        // do stuff
    } catch (TheCheckedException ex) {
        // ignore it
    }

then the code continues even though it could be in a bad state if an exception did occur.

It's a much better solution to let it propagate up the call stack until it can be dealt with appropriately (e.g. by ending the application, giving a 503 error on a web page request, etc.) Unchecked exceptions will propagate up the call stack by default if you don't do anything, making it harder for people to write bad exception handling code.

I like checked exceptions because you can't not deal with the error condition. Swallowed exceptions is a code smell that any half-decent developer will notice, whereas failing to check for some return value is much more subtle. Java allows you to have both, since you can design your exceptions as unchecked, or rethrow a checked exception wrapped in a runtime exception.

So add a 'throws' clause to the method in which you call the code that throws the checked exception and it will propagate upward.

Yes, this! The most irritating debugging I've had to do in Java code is when someone catches an exception, but fails to handle it effectively, resulting in another exception being thrown later. If you don't know how to handle it effectively, just add the 'throws' clause. It's less typing than try/catch, so I don't understand why people choose to make extra work for themselves and for me.

I see a lot of comments here that seem to assume catching the exception is the only option.

Exactly. In Eclipse it's so ridiculously easy to make the method pass it on by adding the throw to your method. I find checked exceptions really useful every day :)

...or rethrow it as an unchecked exception(RuntimeException).

Well, just use runtime exceptions for your own code. (Though, they'll hardly ever change the exceptions in the base libraries to runtime exceptions)

They tend to force you to handle an exception at the wrong level. If you handle them correctly you still have to catch and wrap them at a low-level to not leak an implementation detail in methods signatures. IDE tend to be overly specific on the type of exceptions a method can rise when autofixing methods decls.

In the end you write boilerplate and fight the IDE.