return statement should put beyond try/catch clause??

[Matt]

The return statement should put beyond the try/catch clause, is that
correct? Well,I tried to put inside the try block, but it will have
compile error though.

public String getValue()
{
String value;
try
{
}
catch(...)
{
}
return value;
}

please advise. thanks!!

 

[Liz]

The return statement should put beyond the try/catch clause, is that
correct? Well,I tried to put inside the try block, but it will have
compile error though.

public String getValue()
{
String value;
try
{
}
catch(...)
{
}
return value;
}

please advise. thanks!!

It should be inside the catch block. Move the return statement up one line.

 

[Roedy Green]

The return statement should put beyond the try/catch clause, is that
correct? Well,I tried to put inside the try block, but it will have
compile error though.

you can do it both ways.

If you have the return inside the try you must provide either a throw
or anther return in the catch, after the catch or in a finally. There
must be a route to return whether there is an exception or not.

 

[Jacob]

The return statement should put beyond the try/catch clause, is that
correct? Well,I tried to put inside the try block, but it will have
compile error though.

public String getValue()
{
String value;
try
{
}
catch(...)
{
}
return value;
}

please advise. thanks!!

What you do is essentially correct, but the compiler does
not know which part of the code is executed, and it can
not guarantee that "value" is ever set; thus the compilation
error.

Simply initialize your string at declaration time (for
instance to "null" according to you logic) and the compile
error will go away.

 

[Ryan Stewart]

you can do it both ways.

If you have the return inside the try you must provide either a throw
or anther return in the catch, after the catch or in a finally. There
must be a route to return whether there is an exception or not.

Usually not a good idea to put a return in the finally. It can lead to
unexpected results.

 

[Ryan Stewart]

It should be inside the catch block. Move the return statement up one line.

Just putting a return in the catch block is insufficient. You must provide a
return for every possible path of execution.

 

[Elspeth Thorne]

It should be inside the catch block. Move the return statement up one line.

Or alternatively, in a finally block.

 

[Neal Gafter]

Or alternatively, in a finally block.

You should never have a return statement in a finally block. IN J2SE 1.5.0,
that will trigger a warning from the compiler.

 

[Liz]

What you do is essentially correct, but the compiler does
not know which part of the code is executed, and it can
not guarantee that "value" is ever set; thus the compilation
error.

Simply initialize your string at declaration time (for
instance to "null" according to you logic) and the compile
error will go away.

You don't need a return statement at the end of a method just
prior to the final brace '}'

 

[Guest]

You should never have a return statement in a finally block. IN J2SE
1.5.0, that will trigger a warning from the compiler.

1. Putting a return statement in a finally block:
1.a it is legal and
1.b it is well-defined by Java specification.
2. The warning emitted by the 1.5.0 compiler
will disappear in the final release.

- Dario

 

[Roedy Green]

You don't need a return statement at the end of a method just
prior to the final brace '}'

unless you are returning a value.

 

[Liz]

unless you are returning a value.

tnx, i thought of that after i hit send

 

[Neal Gafter]

1. Putting a return statement in a finally block:
1.a it is legal and
1.b it is well-defined by Java specification.

True. However, its behavior is almost always not what you intend, and should be
avoided unless you're absolutely sure that is what you need.

2. The warning emitted by the 1.5.0 compiler
will disappear in the final release.

False. javac -Xlint will in fact produce this warning in the final release.

 

[Tony Morris]

It should be inside the catch block. Move the return statement up one
line.

Or alternatively, in a finally block.

You just made my stomach churn.
NEVER EVER EVER put a return statement (or throw an exception) from within a
finally block.
Did I say NEVER EVER ? - Good.
NEVER!


Have fun googling to find out why this is extremely poor form.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Tony Morris]

The return statement should put beyond the try/catch clause, is that
correct? Well,I tried to put inside the try block, but it will have
compile error though.

public String getValue()
{
String value;
try
{
}
catch(...)
{
}
return value;
}

please advise. thanks!!

If you throw an exception from within your catch block, you might consider
moving your return statement into the try block:

try {
return value;
}
catch(SomeException se) {
throw new SomeOtherException();
}

This is to satisfy the compile-time error that I'm assuming you are getting.
Without further information, not much more can be said.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Roedy Green]

You just made my stomach churn.
NEVER EVER EVER put a return statement (or throw an exception) from within a
finally block.
Did I say NEVER EVER ? - Good.
NEVER!

Ok ok. But why?

 

[Ryan Stewart]

Ok ok. But why?

Here's one reason from JLS 2.0 §14.16:
"...if there are any try statements (§14.19) within the method or
constructor whose try blocks contain the return statement, then any finally
clauses of those try statements will be executed, in order, innermost to
outermost, before control is transferred to the invoker of the method or
constructor. Abrupt completion of a finally clause can disrupt the transfer
of control initiated by a return statement."

There's also this in §14.19.2 (more readable in the JLS itself):
"A try statement with a finally block is executed by first executing the try
block. Then there is a choice:

* If execution of the try block completes normally, then the finally
block
is executed, and then there is a choice:
o If the finally block completes normally, then the try statement
completes normally.
o If the finally block completes abruptly for reason S, then the
try
statement completes abruptly for reason S.
* If execution of the try block completes abruptly because of a throw of
a
value V, then there is a choice:
o If the run-time type of V is assignable to the parameter of any
catch clause of the try statement, then the first (leftmost)
such
catch clause is selected. The value V is assigned to the
parameter
of the selected catch clause, and the Block of that catch clause
is
executed. Then there is a choice:
+ If the catch block completes normally, then the finally
block
is executed. Then there is a choice:
# If the finally block completes normally, then the
try
statement completes normally.
# If the finally block completes abruptly for any
reason,
then the try statement completes abruptly for the
same
reason.
+ If the catch block completes abruptly for reason R, 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).
o If the run-time type of V is not assignable to the parameter of
any
catch clause of the try statement, then the finally block is
executed. Then there is a choice:
+ If the finally block completes normally, then the try
statement completes abruptly because of a throw of the
value
V.
+ If the finally block completes abruptly for reason S, then
the
try statement completes abruptly for reason S (and the
throw
of value V is discarded and forgotten).
* If execution of the try block completes abruptly for any other reason
R,
then the finally block is executed. Then there is a choice:
o If the finally block completes normally, then the try statement
completes abruptly for reason R.
o If the finally block completes abruptly for reason S, then the
try
statement completes abruptly for reason S (and reason R is
discarded)."

If you consider the implications of the last "*" point there, you'll see
that there could be some unusual effects of returning, throwing, and other
things from a finally block.

 

[Johnny Storm]

Ok ok. But why?

I think what Tony Morris is saying the reason why you don't want to put a
return in a finally block is that you don't know if what you are returning
is correct or not. You'd have to put logic/error checking into the finally
block, which I feel is just bad programming style.
And besides, isn't it kind of redundant? You might as well put the return
statement after the try catch block, and just forget the whole finally part
of it. Does the exact same thing.


Johnny

 

[Chris Smith]

You just made my stomach churn.
NEVER EVER EVER put a return statement (or throw an exception) from within a
finally block.
Did I say NEVER EVER ? - Good.
NEVER!


Have fun googling to find out why this is extremely poor form.

Note that it's impossible to completely avoid throwing an exception (or
more properly, causing an exception to be thrown) from within a finally
block. Code is generally always considered capable of generating an
Error or RuntimeException. Furthermore, it's often more of a bother
than it's worth to avoid throwing even some checked exceptions from
finally blocks. After all, the only negative result is to hide one
error with another. In general, I find that allowing the finally block
to throw an exception is better than the alternative of *not* throwing
an exception when something legitimately goes wrong, just on the off
chance that the finally block was reached through an exception to begin
with.

The warning is far more applicable to a return statement, which risks
swapping an exception for normal completion.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

The return statement should put beyond the try/catch clause, is that
correct? Well,I tried to put inside the try block, but it will have
compile error though.

To take a step back from your other responses, just realize that the
compiler is being smarter than you might think. For instance, it will
allow you to place a return anywhere, but it will require that it
actually reaches a return (or throw) statement in every possible
execution path, *including* error cases.

If you return something inside the try block, then that return will be
missed when an exception is caught, because exceptions cause code to
skip the remainder of the try block and jump directly to catch. You'll
therefore need to provide some kind of return or throw statement in the
catch block as well, so the compiler knows what to do when that
exception actually happens.

Someone else mentioned that you may also be having problems with
'value'. Again, you don't initialize it prior to the try block, and
depending on what's actually in your try block and which exceptions you
catch, it's *possible* that you can forget to ever initialize it if some
error condition happens. If so, the compiler will also see that and
fail to compile for that reason. You then need to think about what your
error handling logic is supposed to be, and do the right thing there.

In the latter case, please don't listen to anyone who tells you to
"fix" your compile errors by initializing your local variable to null
when it's declared. Doing so will silence the compiler, but won't fix
the underlying problem. Then instead of getting a note from the
compiler that your code is broken, it will simply break the first time
that exception happens in production (and, of course, never in testing).
Remember that the compiler is on *your* side, and your goal is to write
working code rather than code that merely compiles. *Never* do
something just because it makes the compiler shut up without first
understanding why the compiler is complaining.

public String getValue()
{
String value;
try
{
}
catch(...)
{
}
return value;
}

please advise. thanks!!

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation