f



JDK 1.4.1 and 1.4.2 differ in compiling

public class Test {    
   static int returnValue() throws Exception {        
     while (true) {
       try {
         break;
       } finally {
         return 1;
       }
     }
  }

  public static void main(String args[]) throws Exception {
    System.out.println(returnValue());
  }
}

When I compile this in JDK 1.4.1_03, I get this error:-

Test.java:xx: missing return statement
protected static int returnValue() throws Exception {
^
1 error

When I compile this in JDK 1.4.2, I get a warning:-

Test.java:xx: warning: finally clause cannot complete normally
}
^
1 warning

JLS 14.14 says,

The preceding descriptions say "attempts to transfer control" rather
than just "transfers control" because if there are any try statements
(�14.19) within the break target whose try blocks contain the break
statement, then any finally clauses of those try statements are
executed, in order, innermost to outermost, before control is
transferred to the break target. Abrupt completion of a finally clause
can disrupt the transfer of control initiated by a break statement.

My question is then what? Is it left to the compilers how they
interpret disruption of transfer of control? How can 1.4.2 generate a
class file when its an error for 1.4.1?

Thanks.

Arnab
0
arnab_nandi
9/5/2003 12:47:56 PM
comp.lang.java 3285 articles. 1 followers. Post Follow

1 Replies
519 Views

Similar Articles

[PageSpeed] 51

arnab_nandi@infy.com (Arnab Nandi) wrote [snipped]:
>   static int returnValue() throws Exception {        
>     while (true) {
>       try {
>         break;
>       } finally {
>         return 1;
>       }
>     }
>
> When I compile this in JDK 1.4.1_03, I get this error:-
> 
> Test.java:xx: missing return statement
> protected static int returnValue() throws Exception {
> ^
> 1 error

This is incorrect.

> When I compile this in JDK 1.4.2, I get a warning:-
> 
> Test.java:xx: warning: finally clause cannot complete normally
> }
> ^
> 1 warning

This is correct. Apparently, there was a bug in 1.4.1 that was fixed
in 1.4.2.

> JLS 14.14 says,
> 
> The preceding descriptions say "attempts to transfer control" rather
> than just "transfers control" because if there are any try statements
> (�14.19) within the break target whose try blocks contain the break
> statement, then any finally clauses of those try statements are
> executed, in order, innermost to outermost, before control is
> transferred to the break target. Abrupt completion of a finally clause
> can disrupt the transfer of control initiated by a break statement.
> 
> My question is then what? Is it left to the compilers how they
> interpret disruption of transfer of control?

Not at all. Java2 Language Spec 14.19.2
(http://java.sun.com/docs/books/jls/second_edition/html/statements.doc.html#236653)
says, for the case illustrated:
  "If execution of the try block completes abruptly for any other
   reason R [meaning not a throw], then the finally block is executed.
   Then there is a choice:
     * If the finally block completes normally, then the try statement
       completes abruptly for reason R.
     * If the finally block completes abruptly for reason S, then the
       try statement completes abruptly for reason S (and reason R is
       discarded)."

Since the try block completes abruptly with a break (not a throw), and
the finally block completes abruptly with a return, then the try
statement completes abruptly with the return (reason S), and the break
(reason R) is discarded.

By the way, note that since (in the example given) the finally clause
will always be executed and will always execute the return statement,
it is impossible for that method to throw an exception. (In the
example, the return value is not calculated, and thus cannot throw an
exception).

   ==========
Now my occasional reminder to those on this newsgroup:

comp.lang.java is not an "official" newsgroup. It was replaced by more
specific newsgroups back in May of 1996. Most people don't see
postings on comp.lang.java, because only a few news servers still
carry it. Google Groups carries it for its historical value, and a few
ISPs (mainly cable-Internet providers) seem to carry it out of
ignorance :-)

The current worldwide Java newsgroups are:

comp.lang.java.3d         3D Graphics API's for the Java language
comp.lang.java.advocacy   Support for and criticism of the Java System
comp.lang.java.announce   Announcements re the Java System (Moderated)
comp.lang.java.beans      Java software components (JavaBeans)
comp.lang.java.corba      Topics relating to Java and CORBA
comp.lang.java.databases  Databases, java.sql, JDBC, ODBC
comp.lang.java.gui        GUI toolkits and windowing: AWT, IFC etc
comp.lang.java.help       Set-up problems, catch-all first aid
comp.lang.java.machine    JVM, native methods, hardware
comp.lang.java.programmer Programming in the Java language
comp.lang.java.security   Security issues raised by Java
0
dougpardee
9/5/2003 11:48:31 PM
Reply: