This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Compiler time error with respect to exception handling Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Compiler time error with respect to exception handling" Watch "Compiler time error with respect to exception handling" New topic
Author

Compiler time error with respect to exception handling

Sirish Kumar
Greenhorn

Joined: Jan 28, 2004
Posts: 15
Hi All,
This is with respect to exception handling. I understand that every method that can throw an checked exception must handle it in one of 2 ways
---- It can declare the checked exception in the throws clause OR
---- It can provide the try/catch block
I noticed this differing behaviour in the 2 approaches.Consider the following method
//Using approach 1
public void raiseException() throws IOException
{
//empty method
}
//Using approach 2
public void raiseException()
{
try
{
//empty block
}
catch(IOException a)
{
}
}
While there was no problem in the first snippet, in case of the second the compiler reports that the java.io.IOException is not thrown..Why is this difference in the behaviour??? This problem remains the same for all the checked exceptions...
Further the problem however is resolved if IOException is replaced with Exception. I was expecting the same behaviour since Exception is also a checked exception.But it was not so...
Any solutions to this one??
Gian Franco
blacksmith
Ranch Hand

Joined: Dec 16, 2003
Posts: 977
Hi,
As the compiler error says for the 2nd code snippet:
"exception java.io.IOException is never thrown in body
of corresponding try statement catch(IOException a)"
Why this doesn't come up if you say catch(Exception a)
I'll leave it to explain by someone else.
But...
An exception can be specified in the throws statement, and
the compiler will not issue an error warning. This means that
users of your method should pretend this exception will really
be thrown. In a later stage of the code development you can then
really start throwing the exception and the users will be ready
for it.
Greetings,
Gian Franco


"Eppur si muove!"
Gian Franco
blacksmith
Ranch Hand

Joined: Dec 16, 2003
Posts: 977
Hi again,
I'll attempt an answer to my first part of the
reply (since no one of the big guys/girls has
seen the topic yet )
It seems plausible to me that no compile error
is given when you replace IOException with
Exception, because if the compiler sees that
there is no checked exception thrown in the
try part of the guarded region, there might
still be a RuntimeException during...runtime.
Since runtime exceptions inherit from the
Exception class they will be caught by the
catch(Exception).
Greetings,
Gian Franco
Sirish Kumar
Greenhorn

Joined: Jan 28, 2004
Posts: 15
Hi Gian,
Abt the compiler allowing us to specify the checked exceptions in the throws clause. As you say, may be that has been provided so that the clients of the method will not be impacted during later stages of the development when the method is implemented. So to start of with we can just specify the likely checked exceptions in the throws clause of the empty method and get away.
I however could not understand the rationale behind allowing the Exception to occur in the catch clause when the try block is empty. After all the RuntimeException / its subclasses are unchecked exceptions. So it is not mandatory to handle/declare them.
Thanks for getting the ball rolling . My question has been partly answered now.. May be once the big guys/girls step in it would be clear
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Compiler time error with respect to exception handling
 
Similar Threads
Catching non-thrown exceptions
Exceptions and interfaces
Compiler time error with respect to exception handling
confusion
Exception Handling