Why do checked exceptions exist in java. What if all exceptions were runtime?

[Monica Shiralkar]

Why do checked exceptions exist in java. What if all exceptions were runtime. Just like Spring JDBC template where only runtime exceptions exist. But why is it not in core java that only runtime exceptions exist.

thanks

[Campbell Ritchie]

Go through the Java™ Tutorials section and it should explain that.

Google for “checked exceptions, an experiment which failed” and you will find the opposite opinion.

[Mike. J. Thompson]

If you look at C++ and Python you'll see it would have been perfectly possible to have created Java without checked exceptions.

Personally I've never had a problem with checked Exceptions, but I also don't have a problem with no checked exceptions. It's important that developers document when exceptions can be thrown if they are not checked though.

[Rob Spoor]

Mike. J. Thompson wrote:Personally I've never had a problem with checked Exceptions

Neither did I, until I started working with lambdas and functional interface. None of the new functional interfaces like Function are allowed to throw any checked exceptions (the existing Callable interface is one of the few readily available functional interfaces that allows checked exceptions). That means that some lambdas need to become a bit more verbose - instead of just a method call, you need to add a try-catch block.

I only wish that lambdas were implemented so it would be allowed to throw checked exceptions from lambdas, as long as the code around it either catches it or has it as part of the throws clause. Of course that doesn't handle the case where you pass a lambda to a method and the method can catch the exception - the code where the lambda is written is not the same as the code where the lambda is called.

[Stephan van Hulst]

That wouldn't work Rob, because it's never guaranteed when the lambda will be run. Cases in point: passing a lambda to ExecutorService.submit() or SwingUtilities.invokeLater().

I don't really see the problem. You can still pass lambdas that throw a checked exception to methods that accept such an interface. Using a lambda would still be nicer than passing an anonymous class instance. I don't think lambdas make checked exceptions more or less problematic than they already were.

Personally, I love checked exceptions. I hate how often I have to double-check the .NET documentation to see if I'm not forgetting to handle an exception when I'm working with C#.

The problem with checked exceptions is that people don't use them correctly. Most 'lazy' programmers just add the throws declaration to all their method signatures, effectively turning checked exceptions into unchecked ones, or creating confusing APIs.

It's the same problem with operator overloading in other languages. I think it's a great feature. Does the fact that many people abuse it make it a bad feature? The same can be said for object inheritance.

[Stephan van Hulst]

Maybe a nice solution would have been to mark exception definitions that should be checked with some sort of @Checked annotation, and then the compiler could warn about uncaught exceptions, rather than rejecting them outright.

[Rob Spoor]

Stephan van Hulst wrote:That wouldn't work Rob, because it's never guaranteed when the lambda will be run. Cases in point: passing a lambda to ExecutorService.submit() or SwingUtilities.invokeLater().

I know. That's what I meant with my last line - the code where the lambda is written is not the same as the code where the lambda is called.

I don't really see the problem. You can still pass lambdas that throw a checked exception to methods that accept such an interface. Using a lambda would still be nicer than passing an anonymous class instance. I don't think lambdas make checked exceptions more or less problematic than they already were.

I have only one problem with it, and that's the need for extra functional interface simply because the standard ones can't throw checked exceptions. From a recent project of mine:

interface HostAwareFunction<T, R> {
    R apply(T t) throws UnknownHostException;
}

That's just a (trimmed down) copy of java.util.function.Function where the apply function can throw an UnknownHostException. This allows me to use lambdas or method references like InetAddress::getByName. If I would need to have a function that can throw a different type of exception, I have a few options:
1) Use Function with a try-catch block that turns the checked exception into an unchecked exception.
2) Create yet another copy of Function that throws the different type. This may work well if there are just a few exception types to handle, but otherwise the number of interfaces grows drastically. (Since I have only two types this is what I have done.)
3) Change the interface to throw Exception, but then I have to use Exception all over the place.

[Monica Shiralkar]

The problem with checked exceptions is that people don't use them correctly. Most 'lazy' programmers just add the throws declaration to all their method signatures, effectively turning checked exceptions into unchecked ones, or creating confusing APIs.

This is similar to what I do. If my main method calls process method and inside process method a checked exception is thrown, I use throws clause in process method and use try catch in the main method. Is this not the correct approach .In that case what is the correct approach?

[Stephan van Hulst]

It can be the correct approach, but you have to think about whether it is. I was arguing that some programmers don't think about it, and just propagate every exception all the way up.

The throws-keyword changes your public API, which means it should make sense to the user of your method when they read the signature, and not the method body. If a method drive() of a Car throws an EngineOverheatedException, that makes sense. If a method movePossessionsToNewAddress() throws an EngineOverheatedException (because they used a car to move the stuff), that doesn't immediately make sense. In this case, you should wrap the call to drive() in a try-catch statement, and then throw a new AccidentWhileMovingException that wraps the original exception.

[Campbell Ritchie]

Stephan van Hulst wrote: . . . wrap the call to drive() in a try-catch statement, and then throw a new AccidentWhileMovingException that wraps the original exception.

Or maybe
Thread.sleep(timeTillEngineCoolsDown);
… which will handle the overheating Exception.

Of course Threadd#sleep declares a checked Exception, which has to be handled too.

[Stephan van Hulst]

Right, if a piece of code has a meaningful way of dealing with an exception without user interference, it can do just that. If it can't, then keep propagating it upwards (rewrapping in a new meaningful Exception type if it makes more sense) until you reach a layer of the application where the user can interact with it. Usually this just means that a user gets a dialog window saying something went wrong.