Unreachable, return in finally or catch

[Zac Roberts]

Here is the code from JQ+:

public class HeeHoo {
 static String j = "";
 public static void method( int i) {
  try {
   if(i == 2) {
    throw new Exception();
   }
   j += "1";
  }
  catch (Exception e) {
   j += "2";
   return;
  }
  finally {
   j += "3";
  }
  j += "4";
 }
 public static void main(String args[]) {
  method(1);
  method(2);
  System.out.println(j);
 }
}

This prints 13423 and I understand that but does anyone know why a return statement in catch does not make the statement below finally unreachable. It seems a return statement in catch is OK but if the return was in the finally block we would have an unreachable statement. Just curious.
Zac

[Corey McGlone]

Originally posted by Zac Roberts:
...does anyone know why a return statement in catch does not make the statement below finally unreachable...

The compiler knows only that the code within the try block might throw an exception. Therefore, the catch block might or might not get executed. Since the catch block might not get executed (at least as far as the compiler knows), execution may pass from the try block to the finally block and then to the line of code following the finally block.
You see, the compiler doesn't look closely enough at the code to realize that an exception will be thrown every time the try block is executed. It "sees" only the format, that being a try/catch/finally block and knows the general behavior of that pattern. It follows those general rules. In this case, you're smarter than the compiler.
I believe, if you put the return into the finally block, the line after finally would become unreachable because the compiler knows that a finally block will always be executed. According to the compiler, however, the catch block might or might not be executed.
I hope that makes sense,
Corey

[Zac Roberts]

That's a great answer, thanks. Is it just me or are there some other situations where the compiler does check all of the cases, such is with a switch statement. I seem to remember that if you have a final variable that is declared but not initilized, you must initilize it in all cases for the code to compile correctly. Does anyone remember anything like this?

[Corey McGlone]

Originally posted by Zac Roberts:
That's a great answer, thanks. Is it just me or are there some other situations where the compiler does check all of the cases, such is with a switch statement. I seem to remember that if you have a final variable that is declared but not initilized, you must initilize it in all cases for the code to compile correctly. Does anyone remember anything like this?

Hmmm...I'm not sure exactly what you mean, Zac. This is my best guess at what you're getting at:

public static void main(String[] args) 
{
   final int i;
   int j = 2;
   switch (j)
   {
      case 0:  i = 0;  // 1
               break;  // 2
      case 1:  i = 1;
               break;
      case 2:  i = 2;
               break;
      case 3:  i = 3;
               break;
      default: i = -1;
               break;
   }
   int k = i;
}

In this case, the compiler has to look a little more closely at your code because a switch statement can be rather complex.
In this case, the final variable i is going to be used to initialize the variable k after the switch statement is complete. That switch statement is therefore responsible for initializing the final variable, i.
In order to be sure that i is initialized before it is used, every case in the switch statement must explicitly assign a veriable to i. (Or execution can "fall through" to a case which does.)
Try commenting out either line 1 or 2 or both. You should see different results in each case. Commenting line 1 out will cause an error stating that the final variable i might not have been initialized before use. If you comment out line 2, you'll get an error because the final variable i might be assigned to twice, which is illegal. If you comment out both, it works fine - see if you can see why.
Also, you need to have a default case in order to ensure that i is set. I suppose, if you had a case for every possible integer, you wouldn't have to but, if you try that, I'll see you next year when you're done typing.
I'm not sure if this is what you were talking about, but you can see that the compiler is forced to take some extra care when it comes to switch statements.
Corey

[Zac Roberts]

Yep thats exactly what I was talking about. Thanks for the explanation. The compiler makes sure that we have initialized i in every single case... so for example, this does not compile becuase i has not been initialized in the default case:

public class SwitchTester {
public static void main(String[] args) {   
 final int i;   
 int j = 2;   
 switch (j)   {      
  case 0:  
   i = 0;  // 1               
   break;        
  case 1:  
   i = 1;               
   break;      
  case 2:  
   i = 2;               
   break;      
  case 3:  
   i = 3;               
   break;      
  default:               
  break;   
 }   
 System.out.println(i);
}

Fails to compile unless we say i = something in the default case. I think i've got it down so hopefully this will turn up on my exam.
Zac