• 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

unreachable statement as to catch clause

 
Ranch Hand
Posts: 186
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all, pls. consider the following 2 classes.
The first class is complained by complier, while the other is complied cleanly.

I find a applicable specification as follows:



A catch block C is reachable iff(if and only if) both of the following are true:
Some expression or throw statement in the try block is reachable and can throw an exception whose type is assignable to the parameter of the catch clause C. (An expression is considered reachable iff the innermost statement containing it is reachable.)
There is no earlier catch block A in the try statement such that the type of C's parameter is the same as or a subclass of the type of A's parameter.


Here my puzzle:
Does it mean that unreachable statement could be acceptable in some special cases(e.g. the unreachable statement in the catch clause of which the exception parameter is of subclass of RuntimeException)?
Or that an empty block(i.e {}) is considered a potential RuntimeException thrower? in this case, the statement enclosed in the catch clause is not considered unreachable.
I know that non-checked exception that can result from execution need not to be mentioned in the throws clause, but the specification of "unreachable statement" does not give such a similar rule. So, don't just simply say that RuntimeException is not taken into account.
Hope some guru would enlighten me, thanks in advance.
James
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I suspect the reason is because IOException is a checked exception and ArithmeticException is not. Try substituting IOException with some other checked exception and ArithmeticException with some other type of RuntimeException and see what happens. I bet that the compiler will complain with any checked exception and accept unchecked exception.
Junilu Lacar
 
James Du
Ranch Hand
Posts: 186
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Junilu,
Thanks for reply,I could predict what happened if I exchange the IOException with the ArithmeticException and I'm sure that the sticking point must be here, but why?
Pls. look at the specification I provided, according to that, the statement in the try clause(i.e System.out.println("Inside Catch"); ) of class B should be regarded unreachable and should be objected by compiler reglardless of the exception type in the try clause.
Let me try explain it in another way, if the statement could be regarded acceptable by the complier(i.e means reachable here), it must conform to either condition in the specification.
Regards,
James
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
James,
The compiler complains that "exception java.io.IOException is never thrown in body of corresponding try statement" so it seems that there is some other part of the specification involved. I looked around a bit and I think you'll find your answer in Chapter 11 of the specification.
Junilu

Originally posted by James Du:
Let me try explain it in another way, if the statement could be regarded acceptable by the complier(i.e means reachable here), it must conform to either condition in the specification.


 
James Du
Ranch Hand
Posts: 186
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Junilu,
I have looked the chapter11 through without any ideal outcome.
Do you think an empty block(i.e {}) could be considered a potential RuntimeException thrower?
Regards,
James
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't think it has anything to do with being unreachable or an empty statement being considered as a potential thrower of a RuntimeException as much as it has to do with the compiler not caring to do compile-time checks for unchecked exceptions/errors. See JLS 11.2.2 Why Runtime Exceptions are Not Checked. What probably happens is that the catch block is optimized out, much like an "if (false) {}" statement will be optimized out of the resulting byte code. Perhaps you could do a hex compare on the class files generated by having an empty method vs. a try-catch (RuntimeException e). If they are identical, then that would prove that the compiler optimized the try-catch block out.

Junilu Lacar

[This message has been edited by JUNILU LACAR (edited April 30, 2001).]
 
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey guys i have addition to make if u change class B's run time exception with simple "Exception" it will also compile cleanly.Now i think Exception type is a checked exception.
Any comments on that ???
Regards
Denish
 
James Du
Ranch Hand
Posts: 186
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I think jls is not all-sided enough regarding the problem, any moderator would step in and clear my doubt up?
Regards,
James
 
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
java does not allow check exceptions to be handled if they are never thrown by any expressions in the try block.it allows you to declare throws clause in the metod signature even if no expressions in the method throw any checked exceptions.we can keep RuntimeException or Exception or Throwable in catch block even when try block is empty.
jeena
 
James Du
Ranch Hand
Posts: 186
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi jeena,
Could you tell me where the following rule appear? jls or somewhere else?


origally stated by jeena

java does not allow check exceptions to be handled if they are never thrown by any expressions in the try block.


[This message has been edited by James Du (edited May 08, 2001).]
 
Ranch Hand
Posts: 3141
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi James,


Here my puzzle:
Does it mean that unreachable statement could be acceptable in
some special cases(e.g. the unreachable statement in the catch
clause of which the exception parameter is of subclass of
RuntimeException)?
Or that an empty block(i.e {}) is considered a potential
RuntimeException thrower? in this case, the statement enclosed in
the catch clause is not considered unreachable.


I think you have to read between the lines in the JLS to answer this. To repeat the rules:
JLS�14.20 Unreachable Statements



  • The try block is reachable iff the try statement is reachable.
  • A catch block C is reachable iff both of the following are
    true:
  • Some expression or throw statement in the try block is
    reachable and can throw an exception whose type is assignable to
    the parameter of the catch clause C. (An expression is considered
    reachable iff the innermost statement containing it is
    reachable.)
  • There is no earlier catch block A in the try statement such
    that the type of C's parameter is the same as or a subclass of
    the type of A's parameter.


In your example, the <code>try</code> block is empty. It is reachable and can be executed successfully.
The rules for RuntimeExceptions are that they can be thrown anywhere, at anytime. The compiler does not specifically look for them (JLS�11.2.2). Theoretically, an empty try block, or any section of code can throw a RuntimeException. This satisfies the first condition for the <code>catch</code> block execution.
The example does not declare any earlier exception of the same type, this satisfies the second condition.
The Java Virtual Machine Specification �2.16.12 states:


Whether a particular catch clause handles an exception is determined by comparing the class of the object that was thrown to the declared type of the parameter of the catch clause. The catch clause handles the exception if the type of its parameter is the class of the exception or a superclass of the class of the exception. Equivalently, a catch clause will catch any exception object that is an instanceof the declared parameter type.


Since a RuntimeException is assumed to be throwable at any point in the execution; no rules are being broken. The catch clause refers to a RuntimeException; this is of a type which can be thrown therefore the catch block is reachable.
Hope that helps.
------------------
Jane Griscti
Sun Certified Programmer for the Java� 2 Platform

[This message has been edited by Jane Griscti (edited May 08, 2001).]
 
James Du
Ranch Hand
Posts: 186
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jane, thanks for your insightful explanation.
It's the statement that clarified my doubt!


originally posted by Jane

Theoretically, an empty try block, or any section of code can throw a RuntimeException.


So, an empty block(i.e {}) can be considered a potential RuntimeException thrower.
Thanks again
James
 
I was her plaything! And so was this 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