compiler warning

D

dennishancy

When compiling my application, I am getting this warning msg:

---------
warning: finally clause cannot complete normally
---------

I get this warning once for every finally clause in my code.

What does this mean? What can I do to fix this?

Thanks in advance.


Dennis Hancy
Eaton Corporation
Cleveland, OH
 
C

Chris Smith

When compiling my application, I am getting this warning msg:

---------
warning: finally clause cannot complete normally
---------

I get this warning once for every finally clause in my code.

What does this mean? What can I do to fix this?

You're doing something that you shouldn't do in your finally clauses.
If you post an example of code that does this, we could offer more help.

"Completing normally" is a technical term in the Java Language
Specification. It means finishing a block of code because you run into
the end of it and have no more code to run. A block of code can also
complete ABNORMALLY by:

1. Encountering a return, break, or continue statement.
2. Throwing an exception that isn't handled within that block.

Finally blocks should generally be able to complete normally. Although
the language specification doesn't require it, it just makes sense.
Hence the warning. As an example, you might write this:

try
{
doSomeIO();
}
finally
{
cleanup();
return;
}

The problem is that the return statement prevents the finally block from
completing normally. If doSomeIO() throws an exception, that exception
will be completely lost without a trace. That's because when a finally
block completes abnormally, any exceptions are lost and the program
continues in whatever way the finally block told it to. In this case,
that means returning from a method, NOT throwing whatever exception got
you to the finally block in the first place.

There is some debate about whether a finally block should EVER complete
abnormally in case of a second error, for example. However, ever
finally block should complete normally at least as the main case,
possibly with exceptions being thrown in the oddball cases.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
H

Harry Bosch

You must be using an older compiler (1.3.x?). The newer compilers
enforce the spec and do not allow return statements within a finally
block(thank god) AFAIK.
 
T

Thomas Hawtin

Harry said:
You must be using an older compiler (1.3.x?). The newer compilers
enforce the spec and do not allow return statements within a finally
block(thank god) AFAIK.

class F { void f() {try { } finally { return; }}}

Works for me.

However if I add -Xlint:finally (from 1.5 onwards), I do get a warning.

C# doesn't allow return in finally.

Tom Hawtin
 
P

Patricia Shanahan

Harry said:
You must be using an older compiler (1.3.x?). The newer compilers
enforce the spec and do not allow return statements within a finally
block(thank god) AFAIK.

Which specification prohibits return statements within a finally block?
Can you give a reference?

Patricia
 
D

dennishancy

My finally clauses are pretty simplistic. They look like this:

finally {
return(vRet);
}

where vRet is declared as follows.

Vector vRet = new Vector();


Thanks.


Dennis
 
J

jan V

My finally clauses are pretty simplistic. They look like this:
finally {
return(vRet);
}

But that makes no sense at all... ! Can you explain what you're trying to
achieve by this?

(and by the way, you don't need to add parentheses for a return... you make
it look like it's a method call when it's not)
 
P

Patricia Shanahan

My finally clauses are pretty simplistic. They look like this:

finally {
return(vRet);
}

where vRet is declared as follows.

Vector vRet = new Vector();


Thanks.


Dennis

Here's the issue. Without seeing the rest of your code, I don't know
whether you have already taking this into account and coped with it.

When a finally clause completes abruptly, completes by throwing
something or returning, the whole try-catch-finally completes abruptly
for the same reason, losing the original completion condition.

Suppose something went really, really bad during the try clause, and an
Error was thrown. Unless you are catching and logging that Error, it
will be completely lost when the finally returns.

Patricia
 
T

Tor Iver Wilhelmsen

Patricia Shanahan said:
Which specification prohibits return statements within a finally
block? Can you give a reference?

A "return" counts as abrubt completion - not normal completion (JLS
§14.1). But I cannot see anywhere (§14.20.2) that prohibits a finally
block from completing abruptly. However, when it does, any Throwable
that may have been thrown, or any return value from the try block, is
lost.

E.g. the following method will return 16:

public static int foo() {
try {
return 42;
}
finally {
return 16;
}
}

I'd say it's bad practice to have the finally block complete abruptly,
but it's not against the spec.
 
T

Thomas Hawtin

Tor said:
I'd say it's bad practice to have the finally block complete abruptly,
but it's not against the spec.

I'm happy with finally blocks throwing exceptions. If the try threw then
one exception must be dropped. If there was a failure in the finally
block then it would be at least as important as the exception it blocks.

Sometimes it can be useful to structure code as:

boolean success = false;
try {
...
success = true;
} finally {
if (!success) {
...dispose of resources...
}
}

I guess you could return if success was true in that finally block.
Don't know why you'd want to though.

Tom Hawtin
 
T

Thomas G. Marshall

Patricia Shanahan coughed up:
Which specification prohibits return statements within a finally
block? Can you give a reference?


And I'm not convinced that it is a particularly useful restriction worthy of
any hissy fit ;) from the compiler engineers at sun. Save for a minor slap
in the face to the structured programming zealots (which I condone anyway),
I just don't see the problem.
 
T

Thomas G. Marshall

Patricia Shanahan coughed up:
Here's the issue. Without seeing the rest of your code, I don't know
whether you have already taking this into account and coped with it.

When a finally clause completes abruptly, completes by throwing
something or returning, the whole try-catch-finally completes abruptly
for the same reason, losing the original completion condition.

Suppose something went really, really bad during the try clause, and
an Error was thrown. Unless you are catching and logging that Error,
it will be completely lost when the finally returns.

Hmmmm.... That's a fairly clear point.

However, it still seems to me as a very small problem. Worrying about
whether or not the catch code is /itself/ protected seems maybe a little too
protective. I'll think on this some more.
 
H

Harry Bosch

Wow, I was wrong. I swore it was in the specification. I just read
over it and it's not there. I guess I just remembered wrong. But, I
believe I was using a compiler that enforced this.

But, I still say that it should not be done.
 
D

Dale King

Thomas said:
Patricia Shanahan coughed up:

And I'm not convinced that it is a particularly useful restriction worthy of
any hissy fit ;) from the compiler engineers at sun. Save for a minor slap
in the face to the structured programming zealots (which I condone anyway),
I just don't see the problem.

Then I don't think you are looking hard enough.

Take this method:

public int foo() throws Exception
{
try
{
bar();
return 1;
}
catch( IOException e )
{
return 2;
}
finally
{
return 3;
}
}

Quick, without thinking too hard about it, what happens in these cases:

- bar completes normally
- bar throws an IOException
- bar throws an exception other IOException

While you a seasoned veteran probably can figure out the answers don't
you think the fact that it returns 3 in all cases might be confusing to
a newbie?

If there were a valid use case for having a return statement in a
finally block then there might be a reason to not have the warning.

Since there isn't a good use case for it and the behavior will be
confusing to newbies and possibly cause undesirable behavior then it is
a good idea to warn people.
 
T

Thomas G. Marshall

Dale King coughed up:
Then I don't think you are looking hard enough.

You might not be looking hard enough at the dates of the replies. Above
you'll see that patricia set me rethinking this already over a week ago.

....[rip]...
 
D

Dale King

Thomas said:
Dale King coughed up:



You might not be looking hard enough at the dates of the replies. Above
you'll see that patricia set me rethinking this already over a week ago.

Unfortunately, the order they were in the thread was not the same as
they were chronologically due to multiple thread forks. It looked to me
like you were rethinking it then you concluded that it was not still a
problem.

I think the example however explained the issue concisely.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top