how does the return statement work in try catch block?

[Mohan Mehra]

consider this program :

public class hello {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		int s = new hello().h();
		System.out.println(s);
	

	}
	
	public int h(){
	try{
		int g = 10/0;
			return 5;
		}catch(Exception e){
			e.printStackTrace();
			return  9;
		}finally{
			return 7;
		}

	}

}

the output is 7.

can anybody explain how the flow is working. i understand that there is a divide by zero exception after which the control goes to catch. what about the return statement in catch . why is it overriden by finally

[Tushar Goel]

Because finally have higher precedence. It will executed at any case so whatever written in to finally be executed. So that's why you see return in finally is executed.
There is only 1 case in which finally will not be executed that's when program itself terminated before running reaching finally.

[Mohan Mehra]

Tushar Goel wrote:Because finally have higher precedence. It will executed at any case so whatever written in to finally be executed. So that's why you see return in finally is executed.
There is only 1 case in which finally will not be executed that's when program itself terminated before running reaching finally.

what about the return in catch?

[Paweł Baczyński]

Mohan Mehra wrote:what about the return in catch?

It does not matter. If you have a return statement in finally block, this return always is executed (unless the application is closed before it reaches this return statement).

[Tushar Goel]

that one too ignored or say its output is overwrite when finally clause runs and shows you output of return mentioned in the finally...

[Mohan Mehra]

thanks for the info

[Winston Gutkowski]

Mohan Mehra wrote:what about the return in catch?

I think what you want is a mechanical explanation as to why the other two 'return's are ignored, and the simple answer is: I don't know.

My suspicion, however, is that they're deferred until the finally block is evaluated - again, exactly how I don't know, but the presence of the try block may create some sort of internal execution stack.

The simple fact is that it really doesn't matter; it's the syntax that's important:
Any try block that includes a finally clause MUST end up by executing its code, no matter what else happens.

And that's precisely what you're seeing.

Question: Did you ALSO get a stacktrace()?

Winston

[Mohan Mehra]

Paweł Baczyński wrote:

Mohan Mehra wrote:what about the return in catch?

It does not matter. If you have a return statement in finally block, this return always is executed (unless the application is closed before it reaches this return statement).

ok. but i want to know whether the return in catch runs or no. i mean when the control comes in the catch and sees the return what does it do. does it returns 9 and then the return in finally overwrites it?

[Paweł Baczyński]

If you ask if the expression in return is evaluated then the answer is: yes.
The proof:

public class Temp {

    static int foo(int value) {
        System.out.println("foo: " + value);
        return value;
    }

    static int bar() {
        try {
            int a = 1 / 0;
            return foo(1);
        } catch (Exception e) {
            return foo(2);
        } finally {
            return foo(3);
        }
    }

    public static void main(String... args) {
        System.out.println("bar: " + bar());
    }
}

It prints:
foo: 2
foo: 3
bar: 3

[Winston Gutkowski]

Mohan Mehra wrote:ok. but i want to know whether the return in catch runs or no.

And what would that tell you? It plainly has no effect, even if it does; so from a logical point of view, it's irrelevant.

If you really want to know exactly what's going on, I suspect you'll need a p-code debugger (if there is such an animal) that allows you to step through the compiler-generated instructions, but I suspect it'll be a laborious exercise for very little gain.

After all: When you know that, what do you know? You know how your compiler translated your source code; and that's no guarantee that a different one (or new release) might not do it differently.

HIH

Winston

[Campbell Ritchie]

Actually there is a specified order for execution: it is in the Java Language Specification (JLS). It is one of the JLS' less easy to read parts.

[Winston Gutkowski]

Campbell Ritchie wrote:Actually there is a specified order for execution: it is in the Java Language Specification (JLS). It is one of the JLS' less easy to read parts.

Right, but it doesn't appear to include anything specific about return statements and how they work. Clearly, if the catch block in the OP is executed, then there must be some smarts in the executed code to say "yeah, I know there's a return here, but there's also a finally block, so run it instead".

I suppose you could run javap and work out what the differences are with and without a finally block; but to my mind it's basically an "intellectual curiosity" exercise.

Not that there's anything wrong with those; just don't expect any great "insights".

Winston

[Campbell Ritchie]

Yes it does, but I said it wasn't easy to read. It says that if the finally completes abruptly for a reason, then the try completes abruptly for the same reason. And I think the same for catch and finally.
Of course, you need to know what completing normally and completing abruptly mean. They are defined in the same chapter of the JLS and abrupt completion appears to mean all things occurring which transfer control away. That includes return statements.

So, if a finally completes abruptly because it has returned 3, then the try and catch preceding also complete abruptly for the same reason, i.e. because they have returned 3.

try
{
   if (...)
   {
      throw new XYZException(...);
   }
   return 999;
}
catch (PQRException ex)
{
   return 666;
}
finally
{
   return 0;
}

The finally completes abruptly because it returns 0, the try and catch therefore also complete abruptly because they returned 0.

[Mike. J. Thompson]

I do think this is more than just intellectual curiosity. It's important to know whether the finally block runs before or after the return statement in the try or catch block as the answer to that question can completely change the behaviour of the program.

As Pawel's example neatly shows, the expressions in the return statements in the try and catch blocks do get evaluated before the finally block runs, so any side effects of those expressions will be seen.

[Campbell Ritchie]

As Mike points out, the return from the finally “overwhelms” the return values of the try and catch, but does not invalidate any side effects.

[Campbell Ritchie]

I seem to have put an empty code tags block in a previous post. I have deleted it.

[Henry Wong]

Mike. J. Thompson wrote:I do think this is more than just intellectual curiosity. It's important to know whether the finally block runs before or after the return statement in the try or catch block as the answer to that question can completely change the behaviour of the program.

As Pawel's example neatly shows, the expressions in the return statements in the try and catch blocks do get evaluated before the finally block runs, so any side effects of those expressions will be seen.

I too, looked into this years ago. And it was also for intellectual curiosity... And I came to the same conclusion as Paweł. It does everything, including the processing of the return statement -- with the exception of actually returning anything. So, you get all the side effects of the return statement, without the actual return of the result.

Henry

[Campbell Ritchie]

We all know that Exceptions thrown in a finally overwhelm any Exceptions thrown elsewhere, so we don't do anything in a finally which might suffer Exceptions. The same applies to return statements, but people don't always think of that.

[Winston Gutkowski]

Campbell Ritchie wrote:Of course, you need to know what completing normally and completing abruptly mean. They are defined in the same chapter of the JLS and abrupt completion appears to mean all things occurring which transfer control away. That includes return statements.

Ah. Cheers for that. I'd always assumed it meant some sort of crash or unhandled exception; not a return.

Just goes to show - I shouldn't ASS-U-ME.

Winston

[Winston Gutkowski]

Mike. J. Thompson wrote:I do think this is more than just intellectual curiosity. It's important to know whether the finally block runs before or after the return statement in the try or catch block as the answer to that question can completely change the behaviour of the program.

Not semantically it doesn't. It does exactly what you'd expect: return the value associated with the finally block.

Exactly how it does it may be of interest to those who love poking about in assembler-style code - and like I say, I have no problem with intellectual curiosity (I'm guilty of it myself) - but I'd still say that it's not of any great importance to a Java programmer.

That said, I've learnt something new in this post; so perhaps there is something to mucking about with bits and bytes...

Winston

[Campbell Ritchie]

Bits and bytes is the easy way to do it. I had to do it the hard way: read the JLS