• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Ranch Hand
Posts: 2925
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Saloon Keeper
Posts: 15510
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 15510
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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:
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
Ranch Hand
Posts: 2925
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Saloon Keeper
Posts: 15510
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Saloon Keeper
Posts: 15510
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
expectation is the root of all heartache - shakespeare. tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic