What's the problem?

[David Cuesta]

public class Test1{
int test(boolean b){
int i;
try{
if(b) return 1;
i=2;
}finally{if(b) i=3;}
return i;
}
public static void main(String h[]){
new Test1().test(true);
}
}
compile fine, but runtime error:
Exception in thread "main" java.lang.VerifyError: (class: Test1, method: test signature: (Z)I) Register 2 contains wrong type
can somebody explain me?
Thanks

[Rick Salsa]

Hi David,
You declare a local variable in method test(). Local variables have to be initialized before being used, otherwise it will throw an exception or the complier will complain. In this case it throws an execption. If you initialize i before you use it, your code works fine.

public class Test1{
int test(boolean b){
int i=0;
try{
if(b) return 1;
i=2;
}finally{if(b) i=3;}
return i;
}
public static void main(String h[]){
new Test1().test(true);
}
}

/rick
[ February 26, 2002: Message edited by: rick salsa ]

[Erik Dark]

I read the JLS on this (12.3.1) but it's rather cryptic....
Found that when int i on line 3 is made an instance variable it runs....
HTHBAID (hope this helps but afraid it doesn't)
Erik Dark

[Brian Lugo]

Does anybody wants to take a shot on this one?
I think it throws an Error and not an Exception, this does not seem to be a initialization problem that the compiler normally catches.
I could not figure out the problem ...
[ February 26, 2002: Message edited by: Brian Lugo ]

[Erik Dark]

..otherwise it will throw an exception or the complier will complain

But the compiler didn't complain and an Error was thrown...(or am I missing something? I agree on the initialization of local variables when declared)

[Brian Lugo]

I could'nt find much info on java.lang.VerifyError. Does anybody know exactly what causes this error?
Brian

[Rajinder Yadav]

There seems to be a few things wrong with your program that maybe be causing the compiler to generate really bad code...sorry
i) your code dose not explicitly throw an exception, nor do any statements cause one to be thrown, so you don't need a try/finally block
ii) following i) the return i; statement at the end of test() may never get executed because of the way you have set up your try/finally block
the compiler assumes that an exception is possible, because you used a try/finally block, so it happily generates code to expect an exception to occur sometime during the lifetime of your program... we humans can see that an exception other than an internal JVM will never occur! but the compiler can't see this...do you get me?
one way to rectify the problem is to put a catch handler in your code, also you will need to init your local var i, since then it's possible to reach the end of test() without variable i ever bing initialized, because if an exception were to be thrown inside the try block before we reached i=2; and if b was false then in the finally block, var i would not get set to any value!
maybe someone else can explain it a bit better?
i added a fix so your program would also run
Q: what are you trying to do, or test? Why are you using a try block?

public class Test1{
   int test(boolean b){
      int i=0;
      try{
         if(b) return 1;
         i=2;
      }
      catch(Exception e) {
      }
      finally{
         if(b) i=3;
      }
      return i;
   }
   public static void main(String h[]){
      new Test1().test(true);
   }
}

[ February 26, 2002: Message edited by: Rajinder Yadav ]

[Rick Salsa]

Rajinder,
That's the same thing that I did. I noticed that as soon as I put a catch statement in, the compiler complained that variable i might not be set. So I think your explaination sums it up very nicely. I haven't been able to find anything on java.lang.VerifyError
Maybe Valentin can come give us an answer. He seems to know the JLS inside and out!!

otherwise it will throw an exception or the complier will complain.

Oops, that's right, only a compile time error, not an exception.
/rick
[ February 26, 2002: Message edited by: rick salsa ]

[Rajinder Yadav]

Here is a sample code I wrote to explain try/catch/finally
NOTE: the message "Leaving the try block" is never printed to the console!

public class Test {
   public static void main(String[] args) {
      System.out.println("Entering main()");         
      try {
         System.out.println("Entering the try block");         
         int i=10/0;
         System.out.println("Leaving the try block");                  
      }
      catch(ArithmeticException e) {
         System.out.println("An exception was thrown!");                  
      }
      finally {
         System.out.println("The finally block always executes");                  
      }
      System.out.println("Leaving main()");         
   }   
}

[Rajinder Yadav]

Brian, the JDK API reference manual states
java.lang.VerifyError
IS
Thrown when the "verifier" detects that a class file, though well formed, contains some sort of internal inconsistency or security problem.

Originally posted by Brian Lugo:
I could'nt find much info on java.lang.VerifyError. Does anybody know exactly what causes this error?
Brian

[Rick Salsa]

Thanks Rajinder. That clears it up for me..
/rick

[Brian Lugo]

Hi Rajinder!
This does not tell me much:
"contains some sort of internal inconsistency or security problem."
I guess what your example demonstrates is :
"The compiler does not check expressions like
int i = 10/0;
to determine if a statement is reachable or not."
Try putting this in the main:
int j = 5;
if (j>5)
System.out.println("This statement is unreachable");
The code will compile and run fine.
Brian
PS - Rajinder I agree to some extent to your argument about comiler's assumption of "unreachable" return statement in the original code. But as you can see from Rick's code that he did not put the catch block and the code compiled and ran fine.
[ February 26, 2002: Message edited by: Brian Lugo ]

[Erik Dark]

Posted by Rajinder:
Thrown when the "verifier" detects that a class file, though well formed, contains some sort of internal inconsistency or security problem.

That was the line I was referring to when talking about a cryptic explanation....could anyone de-crypt in the line of this thread?
Erik Dark

[Rajinder Yadav]

About what the JDK says for java.lang.VerifyError
"Thrown when the 'verifier' detects that a class file, though well formed, contains some sort of internal inconsistency or security problem."
Let me see if I can try to explain part of it's meaning.
javac compiles the source code to java byte code that runs on the JVM, part of the JRE is to verify that the code is consistent and follows the java security model before it is allowed to execute. If the code is found to violate something the JVM will not execute the code!
As for David's original code, it isn't a security risk? but the compiled byte code may have inconsistencies that may provide a security risk.

[Rob Ross]

I think basically you've discovered a compiler bug. Probably the comiler is getting confused somewhere between the try/finally, the various exit points, and the definite assignment of i.
If you comment out this line:
if(b) i=3;
the program runs fine.
What probably happens is that when this line of code runs, the variable i doesn't exist (in the bytecode) because it has not previously been assigned to.
As further evidence that this is a bug in the way it's handling definite assignment, try assigning zero to i when you first delcare it:
int i = 0;
This also fixes the problem.
Basically, you've discovered a very obsure compiler bug. You should report this to Sun.
[ February 26, 2002: Message edited by: Rob Ross ]

[Rajinder Yadav]

Here is what the JLS has to say about code verification
12.3.1 Verification of the Binary Representation
Verification ensures that the binary representation of a class or interface is structurally correct. For example, it checks that every instruction has a valid operation code; that every branch instruction branches to the start of some other instruction, rather than into the middle of an instruction; that every method is provided with a structurally correct signature; and that every instruction obeys the type discipline of the Java virtual machine language.
For the specification of the verification process, see the separate volume of this series, The Java Virtual Machine Specification, Second Edition.
If an error occurs during verification, then an instance of the following subclass of class LinkageError will be thrown at the point in the program that caused the class to be verified:
* VerifyError: The binary definition for a class or interface failed to pass a set of required checks to verify that it obeys the semantics of the Java virtual machine language and that it cannot violate the integrity of the Java virtual machine. (See �13.4.2, �13.4.4, �13.4.8, and �13.4.15 for some examples.)

[Junilu Lacar]

Very interesting...
Yet another reason not to return from a try block. I have to go with Rob on this. It looks like a compiler bug.
Junilu