return statement should put beyond try/catch clause??

[Guest]

True. However, its behavior is almost always not what you intend,

Writing programs (in C, Java, C#, etc..)
I never intend any particular behavior
but I always use the behavior specified by the
corresponding language specification.

and should be avoided unless you're absolutely sure that is what you need.

I repeat myself:
Writing programs (in C, Java, C#, etc..)
I never intend any particular behavior
but I always use the behavior specified by the
corresponding language specification.
so I use any feature that the language give me.

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

I always pay great attention to any warning emitted
by my Java compilers (Sun, IBM, and others).
Sometime they are useful, sometime not.

- Dario

 

[Ryan Stewart]

Writing programs (in C, Java, C#, etc..)
I never intend any particular behavior

So you just randomly combine words and hope for something useful? That seems
inefficient.

 

[Timo Kinnunen]

Writing programs (in C, Java, C#, etc..)
I never intend any particular behavior
but I always use the behavior specified by the
corresponding language specification.

Are you really comfortable essentially writing

try {
// do something
} catch(Throwable ignored) {}
return whatever;

The things that you might ignore include but are not limited to
OutOfMemoryError, InternalError, UnknownError and ThreadDeath. Is the JVM
allowed to shut itself down by calling Thread.stop() on all running
threads? If so, you might be preventing it from shutting down gracefully.

 

[Neal Gafter]

Writing programs (in C, Java, C#, etc..)
I never intend any particular behavior

You may have a hard time getting hired as a programmer.

 

[Roedy Green]

What do you mean my that? Literally it is nonsense. Are you telling us
you enjoy just randomly gluing bits of Java together, with the
intention you just want it to do anything that might be entertaining,
surprising or enlightening?

To me the initial appeal of computer programming was the degree of
perfection and control you could gain. I loved the lack of ambiguity
that plagued even mathematics.

 

[Tony Morris]

Writing programs (in C, Java, C#, etc..)

I never intend any particular behavior
but I always use the behavior specified by the
corresponding language specification.

What on earth does that mean?
You throw some language constructs together such that you have a compilable
unit, then you "use the behavior specified by the
corresponding language specification."?

As Neal pointed out, the 1.5 compiler will issue a warning when you violate
the language like this.
I've asked Neal to have the Sun compiler fail completely when the user has
no electrical charge in their brain, but to no avail, and unfortunately,
we'll likely see these abuses in times to come.

--
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]

That is like saying you are omniscient and never misunderstand the
language spec. It could also be interpreted that you worship the spec,
and claim to have no desires of your own. What ever result the
compiler gives, is by definition what you wanted.

It sounds so funny, I'm sure what you intended was quite different.

 

[Guest]

So you just randomly combine words and hope for something useful? That seems
inefficient.

LOL.

But I do not write:

Writing programs (in C, Java, C#, etc..)
I never intend any particular behavior

Instead I write:

Writing programs (in C, Java, C#, etc..)
I never intend any particular behavior
but I always use the behavior specified by the
corresponding language specification.

Have you noticed the final dot "."?

- Dario

 

[Roedy Green]

There are definite answers to these questions, but I bet many
programmers could not tell you the answer with confidence. And
there has probably been at least one version of some compiler got
it wrong, so it is probably not be wise to rely on it.

Good answer, thanks.

 

[Chris Smith]

Instead I write:

Have you noticed the final dot "."?

This makes as little sense as before, though. You do intend the code to
do something, of course. Furthermore, we can make generalizations about
what is intended... in this case, we find it unlikely that you really
intend for code to have the same normal completion and return value
regardless of whether an exception occurred or not. The point is that
the actual behavior of the code that is being discussed exhibits a
behavior that is very rarely actually intended.

In any case, maybe it is what you intend in a specific situation where
you've written it. The facts remain that:

1. You're missing documentation opprotunities. Wouldn't it be better to
use a catch block to hold a comment indicating why it's okay to complete
normally despite this exception, and give no indication that it
occurred?

2. You're writing code that is definitely quite confusing to others.

3. You're writing code that breaks using some versions of some compilers
(IIRC, an older version of Jikes).

Basically, you'd better have a darn good justification for doing this.
Since it's trivially possible to accomplish any result without return
statements in finally blocks, I have trouble seeing such a good reason.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Guest]

Since it's trivially possible to accomplish any result without return
statements in finally blocks, I have trouble seeing such a good reason.

It has been demonstrated, many years ago, that any recursion may be
accomplished with iteration.
Nevertheless I like to have recursion in my language.

It has been demonstrated, many years ago, that using a language
with only "if" and "goto" as control-structures
you can make everything (computable of course!) you want.
Nevertheless I like to have "while", "for", "break", "continue",
method invocation, etc.. in my language.

Analogously I like to use well-defined features in Java.
Certainly you are free to rewrite some fragment of my Java sources
using differens structures. But I use these features
because in Java they are well-specified so any JVM will implement
them in the same manner (apart, obviously, from bugs...).

And again, you say:

it's trivially possible to accomplish any result without return
statements in finally blocks,

So please consider the following fragment of code:
try {
...BlaBlaT...
} catch(Exception e) {
...BlaBlaC...
} finally {
...BlaBlaF...
}
where every ...BlaBlaX... fragment is something like:
...BlaBlaX1...;
if(...BlaBlaX2...)
return ...BlaBlaX3...;
...BlaBlaX4...
if(...BlaBlaX5...)
throw ...BlaBlaX6...;
...BlaBlaX7...

How you _simply_ rewrite the finally part
finally {
...BlaBlaF1...;
if(...BlaBlaF2...)
return ...BlaBlaF3...;
...BlaBlaF4...
if(...BlaBlaF5...)
throw ...BlaBlaF6...;
...BlaBlaF7...
}
maintaining the same semantic of the original fragment of code
and without having a return statement inside?

IMHO this task is not so _trivial_ !

- Dario

 

[Guest]

While a return in finally is allowed it should most certainly be
avoided and is frowned upon. It leads to confusing code. Consider
this code:

try
{
someCode();
return 1;
}
catch( AnException e )
{
throw something;
}
finally
{
return 0;
}

Does this code return 0 or 1 when there is no exception? If the
exception is thrown does the something exception really reach the
caller or does the return in the finally override the exception?
How do the answers change with different combinations of return
and throw?

Assuming someCode() is a method invocation and not a generic
fragment of code (so there is not "return" or "break" or
any other abruptly completions inside someCode())
then there are only 3 cases:
-1- someCode() does not generate any Throwable
=> return 0;
-2- someCode() generate a Throwable t assignable to e
something is created and discarded
=> return 0;
-3- someCode() generate a Throwable t not assignable to e
t is discarded
=> return 0;

So in your example
- every generated exception is always discarded and forgotten
- and the return value is always zero.
Very simple! Or not ?

There are definite answers to these questions, but I bet many
programmers could not tell you the answer with confidence.

What is difficult to understand in
http://java.sun.com/docs/books/jls/second_edition/html/statements.doc.html#236653

And there has probably been at least one version of some compiler got
it wrong, so it is probably not be wise to rely on it.

Every non-stupid program has always errors: and so?
Perhaps only "Hello World" programs are error-free!

- Dario

 

[Chris Smith]

It has been demonstrated, many years ago, that any recursion may be
accomplished with iteration.
Nevertheless I like to have recursion in my language.

You're acting as if there aren't compelling reasons to avoid return from
a finally block. There are. As Dale and I have both pointed out, there
have been major compilers that misinterpret the result, not to mention
human beings. That, along with the fact that replacing returns from
finally is *far* easier than replacing recursion or loop structures --
not to mention that recursion and loop structures solve naturally
occurring problems, while I'd bet money that you can't find a naturally
occurring problem where returning from finally is an appropriate
abstraction -- makes this an entirely different matter.

So please consider the following fragment of code:
try {
...BlaBlaT...
} catch(Exception e) {
...BlaBlaC...
} finally {
...BlaBlaF...
}
where every ...BlaBlaX... fragment is something like:
...BlaBlaX1...;
if(...BlaBlaX2...)
return ...BlaBlaX3...;
...BlaBlaX4...
if(...BlaBlaX5...)
throw ...BlaBlaX6...;
...BlaBlaX7...

That's not code; it's nonsense. Nonsense can't be converted to anything
but nonsense. If you'd like to write some real code, I'd be happy to do
this for you.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Guest]

That's not code; it's nonsense. Nonsense can't be converted to anything
but nonsense. If you'd like to write some real code, I'd be happy to do
this for you.

The following is an actual Java class example.

public class Finally {
private BlaBla b;
public Finally(BlaBla b) {this.b = b;}
public int aMethod() throws Exception {
try {
System.out.println("try");
if(b.BlaBla2())
return b.BlaBla3();
if(b.BlaBla5())
throw b.BlaBla6();
} catch(RuntimeException rte) {
System.out.println("catch "+rte);
if(b.BlaBla2())
return b.BlaBla3();
if(b.BlaBla5())
throw b.BlaBla6();
} finally {
System.out.println("finally");
if(b.BlaBla2())
return b.BlaBla3();
if(b.BlaBla5())
throw b.BlaBla6();
return 3;
}
}
}
interface BlaBla {
boolean BlaBla2();
int BlaBla3();
boolean BlaBla5();
Exception BlaBla6();
}

Now I can re-type my (pedantic) question:
How you _simply_ rewrite the finally part
maintaining the same semantic of the original class
and without having a return statement inside?

- Dario

 

[Chris Smith]

The following is an actual Java class example.

You've made it easier than you needed to, but here's your answer:

public class Finally
{
... // same as your code

public int aMethod() throws Exception
{
try
{
try
{
System.out.println("try");

if (b.BlaBla2()) b.BlaBla3()
else if (b.BlaBla5()) b.BlaBla6();
}
catch (RuntimeException e)
{
System.out.println("catch " + rte);

if (b.BlaBla2()) b.BlaBla3();
else if (b.BlaBla5()) b.BlaBla6();
}
}
catch (Throwable t) { }

System.out.println("finally");

if(b.BlaBla2()) return b.BlaBla3();
if(b.BlaBla5()) throw b.BlaBla6();
return 3;
}
}

Of course, this is the most general possible case. In reality, if some
of those methods are known to have no side-effects and not throw
exceptions, then method calls can be eliminated in a most cases.

Note that the translation also brings out the fact that you're ignoring
Throwable without so much as a log message. That's an extremely bad
idea (for example, you're missing instances of Error), which should
really be eliminated from this code immediately.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Tony Morris]

This is one of those debates where you just have to conclude that
"experience counts".

One day, hopefully soon, this person will fall into the traps presented by
following this practice that has been recommended against by most of us on
this forum (including some very reputable people). Then, and only then,
will that person learn - as opposed to trying to point it out. I'm prepared
to be proven wrong on that.

--
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

 

[Guest]

You've made it easier than you needed to, but here's your answer:

public class Finally
{
... // same as your code

public int aMethod() throws Exception
{
try
{
try
{
System.out.println("try");

if (b.BlaBla2()) b.BlaBla3()
else if (b.BlaBla5()) b.BlaBla6();
}
catch (RuntimeException e)
{
System.out.println("catch " + rte);

if (b.BlaBla2()) b.BlaBla3();
else if (b.BlaBla5()) b.BlaBla6();
}
}
catch (Throwable t) { }

System.out.println("finally");

if(b.BlaBla2()) return b.BlaBla3();
if(b.BlaBla5()) throw b.BlaBla6();
return 3;
}
}

Of course, this is the most general possible case. In reality, if some
of those methods are known to have no side-effects and not throw
exceptions, then method calls can be eliminated in a most cases.

Thanks.

Just a last request (to understand better!).
What change if I move my
return 3;
after the try/catch/block in the following manner:

public class Finally {
private BlaBla b;
public Finally(BlaBla b) {this.b = b;}
public int aMethod() throws Exception {
try {
System.out.println("try");
if(b.BlaBla2())
return b.BlaBla3();
if(b.BlaBla5())
throw b.BlaBla6();
} catch(RuntimeException rte) {
System.out.println("catch "+rte);
if(b.BlaBla2())
return b.BlaBla3();
if(b.BlaBla5())
throw b.BlaBla6();
} finally {
System.out.println("finally");
if(b.BlaBla2())
return b.BlaBla3(); // still here!
if(b.BlaBla5())
throw b.BlaBla6();
// return 3; // moved from here...
}
return 3; // ..to here.
}
}
interface BlaBla {
boolean BlaBla2();
int BlaBla3();
boolean BlaBla5();
Exception BlaBla6();
}

In this case how is your solution without any return
inside the finally block?

Note that the translation also brings out the fact that you're ignoring
Throwable without so much as a log message. That's an extremely bad
idea (for example, you're missing instances of Error), which should
really be eliminated from this code immediately.

I known that.
My learning exercise was just a simple exercise...

- Dario

 

[Chris Smith]

Just a last request (to understand better!).
What change if I move my
return 3;
after the try/catch/block in the following manner:

Now you haven't made it easier than you needed to. The code could look
something like this:

public class Finally
{
... // same as your code

public int aMethod() throws Exception
{
int savedReturn = -1; // or some other unused return value
Throwable savedException = null;

try
{
try
{
System.out.println("try");

if (b.BlaBla2()) savedReturn = b.BlaBla3()
else if (b.BlaBla5()) throw b.BlaBla6();
}
catch (RuntimeException e)
{
System.out.println("catch " + rte);

if (b.BlaBla2()) savedReturn = b.BlaBla3();
else if (b.BlaBla5()) throw b.BlaBla6();
}
}
catch (Throwable t)
{
savedException = t;
}

System.out.println("finally");

if(b.BlaBla2()) return b.BlaBla3();
if(b.BlaBla5()) throw b.BlaBla6();

if (savedException != null) throw savedException;
if (savedReturn != -1) return savedReturn;

return 3;
}
}

This looks a little less natural, but it's far more obvious what happens
when an exception occurs (i.e., that it's saved and only is reported if
you reach a point near the end of the method without returning first).

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Guest]

Now you haven't made it easier than you needed to. The code could look
something like this:

public class Finally
{
... // same as your code

public int aMethod() throws Exception
{
int savedReturn = -1; // or some other unused return value
Throwable savedException = null;

try
{
try
{
System.out.println("try");

if (b.BlaBla2()) savedReturn = b.BlaBla3()
else if (b.BlaBla5()) throw b.BlaBla6();
}
catch (RuntimeException e)
{
System.out.println("catch " + rte);

if (b.BlaBla2()) savedReturn = b.BlaBla3();
else if (b.BlaBla5()) throw b.BlaBla6();
}
}
catch (Throwable t)
{
savedException = t;
}

System.out.println("finally");

if(b.BlaBla2()) return b.BlaBla3();
if(b.BlaBla5()) throw b.BlaBla6();

if (savedException != null) throw savedException;
if (savedReturn != -1) return savedReturn;

return 3;
}
}
Thanks.

This looks a little less natural, but it's far more obvious what happens
when an exception occurs (i.e., that it's saved and only is reported if
you reach a point near the end of the method without returning first).

OK.
Your alternative program is semantically equivalent
to my original exercise.

Personally I will continue to use (in my programs) the finally clause
because I think, IMHO, it is more readable.

Again: many thanks for the time and for the patience
and sorry for my horrible english.

- Dario

 

[Chris Smith]

Personally I will continue to use (in my programs) the finally clause
because I think, IMHO, it is more readable.

That's certainly right. I mainly wanted to be sure that you realize
that doing so hides the fact that you're discarding arbitrary exceptions
(including Error, etc.) without acknowledgement. You've also heard from
elsewhere that very widely used compilers have gotten this wrong, and
that the most commonly used compilers will issue warnings for your code
when you do it. If all that fails to convince you, then you must have
some reason for going ahead.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation