• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Bear Bibeault
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • salvin francis
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Frits Walraven
Bartenders:
  • Jj Roberts
  • Carey Brown
  • Scott Selikoff

NoMoreCarrotsException Mistery

 
Ranch Hand
Posts: 95
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi ranchers.
I'm reading Jeanne and Scott OCA book.
In the last pages dedicated to Exceptions there's a pair of examples I cannot fully understand.
The first code is like that:

It doesn't compile because eatCarrot() doesn't declare a NoMoreCarrotsException and there's really nothing to try and catch in the main method.
Following the compiler rant:
Bunny.java:7: error: exception NoMoreCarrotsException is never thrown in body of corresponding try statement }catch(NoMoreCarrotsException e){
The book regularly explains it.

The second example, few pages later, is dadicated to exceptions printing and it is like that:

This one compiles.

But wait!

hop() like eatCarrot() doesn't declare any exception!
So why the compiler doesn't rant anything about Exception handling in the main method? Isn't it the same case of the first example?
I'm confused.
 
Ranch Hand
Posts: 36
Mac OS X Spring Java
  • Likes 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Daniele Barell wrote:
So why the compiler doesn't rant anything about Exception handling in the main method? Isn't it the same case of the first example?
I'm confused.



Hi Daniele,
The NoMoreCarrotsException extends Exception and hence it is a checked exception, which has to be either handled, or declared in the method to be handled by the caller.
The scenario mentioned in the question tries to handle NoMoreCarrotsException, but it is never declared to be thrown from inside the try block, and compiler knows it, and hence the catch block becomes unreachable and compiler will not be happy.

IllegalArgumentException extends RuntimeException and it is a unchecked exception, and there is no need to declare/handle it.
The reason this one compiles, is the fact that it is catching Exception in the catch block, which can also catch RuntimeExceptions, which the compiler won't be aware about, so it doesn't treat this catch block as unreachable and allows the code to compile.

Hope this helps.
 
Daniele Barell
Ranch Hand
Posts: 95
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ankur!
Thanks for the clear answer!

Ankur R Jain wrote:
The reason this one compiles, is the fact that it is catching Exception in the catch block, which can also catch RuntimeExceptions, which the compiler won't be aware about, so it doesn't treat this catch block as unreachable and allows the code to compile.



So we could safely try and catch the basic Exception all the time because it can also catch RuntimeException which could be thrown by any called method without the need to declare it. Do I correcly understand?
In fact re-writing the Bunny class like that:

It compiles.

But at this point I cannot see the need, at design time, to define the Exception type a checked exception itself. Isn't it sort of misleading?
 
Ankur R Jain
Ranch Hand
Posts: 36
Mac OS X Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Daniele Barell wrote:Hi Ankur!
Thanks for the clear answer!



Happy to help.

Daniele Barell wrote:
So we could safely try and catch the basic Exception all the time because it can also catch RuntimeException which could be thrown by any called method without the need to declare it. Do I correcly understand?



Yes, that is correct.

Daniele Barell wrote:
But at this point I cannot see the need, at design time, to define the Exception type a checked exception itself. Isn't it sort of misleading?



I think there was a need to have a super-type which can contain all the checked and unchecked exceptions. Although it is definitely not recommended to catch using Exception and then provide a solution, because it means it will have a single solution for all the exceptions in the world, which doesn't sound practical.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic