finally block does not complete normally - Eclipse

G

George Cherry

Dale King said:
So if the OP's original code looked like this:

try { fos = new FileOutputStream
(FILENAME); ... // write to file
} finally {
if (fos
!= null)
fos.close();
}

Are you really saying that it would be wrong for him to correct the code
to make it readable?

While we can argue whether or not the opening brace should be hidden at
the end of the line (does that tell you which I choose),

How do you feel about "hiding" semicolons at the end of lines?
the real problem with the OP's code that he corrected was the line: "}
finally {" which I find atrocious.

And I agree with Lee. My experience is that very few use Sun's hidden
brace style.

I believe that most of the best-selling Java books
"hide" the opening brace at the end of the line.
(Just where it belongs.) : o)
My feelings on conventions is that they have to be justified by reasoning
why that convention is best. Just that Sun chooses something does not make
it binding on others. Sun provides no justification for their convention
and there is plenty of justification for balancing the braces.

Would you care to elucidate them?
 
L

Lee Fesperman

George said:
I believe that most of the best-selling Java books
"hide" the opening brace at the end of the line.
(Just where it belongs.) : o)

That was explained earlier --- "... because it takes up fewer lines in a printed book."
The same reason also applies to K&R.
 
G

George Cherry

Lee Fesperman said:
That was explained earlier --- "... because it takes up fewer lines in a
printed book."
The same reason also applies to K&R.

Do you and Dale also abominate "hiding" at the
end of a line something as important as the
parameters passed to a constructor or method?

Do you prefer

List myList = new ArrayList
(20);

to

List myList = new ArrayList(20);

???

A '{' can run to the end of a line, but it can't hide. : o )

The following is from Bruce Eckel's Website, not a book.
(It is taken from a chapterwhich occurs before he introduces
loops.)

//: c02:E07_ShowArgs.java
// {Args: A B C}
/****************** Exercise 7 ******************
* Write a program that prints three arguments
* taken from the command line. To do this,
* you'll need to index into the command-line
* array of Strings.
***********************************************/
public class E07_ShowArgs {
public static void main(String[] args) {
System.out.println(args[0]);
System.out.println(args[1]);
System.out.println(args[2]);
}
}
 
L

Lee Fesperman

George said:
Do you and Dale also abominate "hiding" at the
end of a line something as important as the
parameters passed to a constructor or method?

Do you prefer

List myList = new ArrayList
(20);

to

List myList = new ArrayList(20);

???

You're just carrying things to the extreme. I've never seen a shop that used such a
style. OTOH, I've never seen a shop (this includes C, C++ and Java) that used the old
K&R style ... except for students. "Random alternate style" is preferred, in my
experience.
The following is from Bruce Eckel's Website, not a book.
(It is taken from a chapterwhich occurs before he introduces
loops.)

//: c02:E07_ShowArgs.java
// {Args: A B C}
/****************** Exercise 7 ******************
* Write a program that prints three arguments
* taken from the command line. To do this,
* you'll need to index into the command-line
* array of Strings.
***********************************************/
public class E07_ShowArgs {
public static void main(String[] args) {
System.out.println(args[0]);
System.out.println(args[1]);
System.out.println(args[2]);
}
}

Eckel writes books, so I'm not surprised he uses the same style on his web site.
Besides, this is just example code, not the same as real programming which has wholly
different considerations.
 
G

George Cherry

Lee Fesperman said:
You're just carrying things to the extreme. I've never seen a shop that
used such a
style. OTOH, I've never seen a shop (this includes C, C++ and Java) that
used the old
K&R style ... except for students. "Random alternate style" is preferred,
in my
experience.

LOL. Yes, I've seen that often.
The following is from Bruce Eckel's Website, not a book.
(It is taken from a chapterwhich occurs before he introduces
loops.)

//: c02:E07_ShowArgs.java
// {Args: A B C}
/****************** Exercise 7 ******************
* Write a program that prints three arguments
* taken from the command line. To do this,
* you'll need to index into the command-line
* array of Strings.
***********************************************/
public class E07_ShowArgs {
public static void main(String[] args) {
System.out.println(args[0]);
System.out.println(args[1]);
System.out.println(args[2]);
}
}

Eckel writes books, so I'm not surprised he uses the same style on his web
site.
Besides, this is just example code, not the same as real programming which
has wholly
different considerations.

--
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
 
D

Dale King

George said:
How do you feel about "hiding" semicolons at the end of lines?

No problem with it as long as you are following other practices that
make individual statements easy to see. A single statement is a single
unit. If you do things like keep one statement per line and use visual
cues to indicate when you have to use multiple lines (e.g. indenting the
rest of the statement and separating it from surrounding statements)
then there is little information carried by the semicolon itself.

But we were discussing compound statements. The same logic does not
apply. There we have at least to parts to the statement. For example in
the case of a while you have the loop condition and you have the
statements over which you are looping. In that case there is value in
making that separation distinct. Using braces on their own lines does
this very well. It forms a visual frame around the body but is still
attached to the statement at the top to make it a cohesive unit. This is
enhanced by always using braces and add whitespace above and below to
separate it from other statements (if the thing above or below is a
brace then no blank line as the brace is already a visual separator.

A mental test I like to do is the defocus test. Consider looking at the
code but try not to focus your eyes so that you can't make out the
individual letters and see if you can get a semblance of the structure
of the code without reading the actual letters. The brace on the new
line makes it easier to see.

It seems obvious to me that you have a balanced pair of braces. Why do
you not want to keep them balanced. If Sun wanted to hide the opening
brace then they should have used something else like

if( sdfsa )
asdfas
endif

I believe that most of the best-selling Java books
"hide" the opening brace at the end of the line.
(Just where it belongs.) : o)

Which bears little weight with me.
Would you care to elucidate them?

The style that should be used is the one that makes code easier to read
for the largest number of readers. I and others who have posted in these
groups find that the hidden brace style is harder to read. I am willing
to concede that there are those that can read both equally. For the
hidden brace style to be the one to use there must be a significant
number of people that find it *easier* to read than using the brace to
provide visual separation. I do not concede that such people exist in
significant numbers. I have seen no evidence of their existence.

One could due a scientific study to test programmers speed of
comprehension (and note that this test would not be testing personal
preference. I'm fairly confident of what the results would be.

And as a final comment consider this piece of code from an actual post
to these groups many years ago:
This code will result in auto shutdown immediately after startup. Yet,
if I comment out the call to dispose(), it works fine. That makes no
sense to me because exit() should not be called without the user
calling for the frame to shut down. Why does it self-destruct?
public void processWindowEvent(WindowEvent wE) {
super.processWindowEvent(wE);
if (wE.getID() == WindowEvent.WINDOW_CLOSING)
dispose();
System.exit(0);
}

How long did it take you to find the error? There is no opening brace on
the if so what looks like the closing brace of the if is actually the
closing brace of the method. If you follow the convention that opening
braces are, without exception, on their own line the error leaps off the
page at you.
 
D

Dale King

Mark said:
My responses have always been rational; you might not have *liked*
them, but the truth is often painful. However, I'd worry that you'd
take that very improbable *IF* clause above as license to annoy your
co-workers with your artistic expression.

You never use a coding style for artistic expression. You use a
particular coding style only to make the code easier to read. If a style
is harder to read you should not use it no matter who says to use it.

I have argued at length before about why the brace on its own line is
easier to read, but that is not the main reason I am replying so I will
sidestep that one for now.
The IDE defaults are set that way for a reason,

And it also let's you change them for a reason.
it's not just a
coincidence or following some unpopular style.

Sure, it's the style that the creator of the language uses. It does not
logically follow that is the style that others should use.
K&R set their style that way for a good reason.

That's debatable.
You can go ahead and survey companies if you like, and you will find
that the Sun style guide is followed almost all the time.

Which does not seem to be true.
<boggle> Vertical whitespace actively interferes with reading code,
because it steals valuable vertical space. You have at least 80
columns, but at most 30-odd lines if you want them to be readable, and a
function that's more than a screen long becomes exponentially harder to
understand. This isn't exactly news, this has been known for over 30
years.

Actually quite the opposite is true. One of my favorite and very
profound quotes on the subject is from our own Kent Paul Dolan. I
disagreed with his point (he was concerned with conserving horizontal
whitespace by only using 2 spaces for indentation but the statements
about vertical whitespace are very true:

Horizontal white-space is precious, vertical white-space is cheap.
Screen widths are limited, in Sun's convention to 80 characters
....vertical white-space...exists in effectively infinite supply...

That is a philosophy I live by.

And I would say that the number of lines on a screen is more like 35-40.
Even on my laptop, I have 39 displayed in Eclipse's default font.
You get no benefit from the vertical braces. They duplicate
information that you get from the indentation level (possibly
erroneously),

But the indentation level is not enough of a visual cue. The separation
and give you the opportunity to cause horrible bugs you'll

Sorry, you'll have to explain that one. How can making your code easier
to read provide opportunit to cause horrible bugs?
never find, because nobody who uses vertical braces uses them all the
time.

I guess that makes me a nobody! In the cases of compound statements I
*always* use braces and *always* have them in the same place. I even use
Checkstyle to enforce it. The only place I don't necessarily line up the
braces is for array initializers preferring to keep small ones on one line.
With the K&R style, you can afford the screen space to always use
braces, and make safer code.

I afford it just fine with my style thank you.
It's still unbelievably rude, and sets a bad example, as seen here,
with people actually trying to justify this bad behavior. Terrifying.

You're criticism of *the* most helpful member of these groups is what I
find terribly rude. I also find your assertion that everyone should use
your style very rude. If Chris had done nothing but reformat the code
and that was all he said then your reaction may have been justified. But
he completely answered the OP's question and in the process of
correcting the code used a different brace style than the OP is
perfectly acceptable especially since he only posted 9 lines of code.
 
D

Dale King

George said:
How do you feel about "hiding" semicolons at the end of lines?

No problem with it as long as you are following other practices that
make individual statements easy to see. A single statement is a single
unit. If you do things like keep one statement per line and use visual
cues to indicate when you have to use multiple lines (e.g. indenting the
rest of the statement and separating it from surrounding statements)
then there is little information carried by the semicolon itself.

But we were discussing compound statements. The same logic does not
apply. There we have at least to parts to the statement. For example in
the case of a while you have the loop condition and you have the
statements over which you are looping. In that case there is value in
making that separation distinct. Using braces on their own lines does
this very well. It forms a visual frame around the body but is still
attached to the statement at the top to make it a cohesive unit. This is
enhanced by always using braces and add whitespace above and below to
separate it from other statements (if the thing above or below is a
brace then no blank line as the brace is already a visual separator.

A mental test I like to do is the defocus test. Consider looking at the
code but try not to focus your eyes so that you can't make out the
individual letters and see if you can get a semblance of the structure
of the code without reading the actual letters. The brace on the new
line makes it easier to see.

It seems obvious to me that you have a balanced pair of braces. Why do
you not want to keep them balanced. If Sun wanted to hide the opening
brace then they should have used something else like

if( sdfsa )
asdfas
endif

I believe that most of the best-selling Java books
"hide" the opening brace at the end of the line.
(Just where it belongs.) : o)

Which bears little weight with me.
Would you care to elucidate them?

The style that should be used is the one that makes code easier to read
for the largest number of readers. I and others who have posted in these
groups find that the hidden brace style is harder to read. I am willing
to concede that there are those that can read both equally. For the
hidden brace style to be the one to use there must be a significant
number of people that find it *easier* to read than using the brace to
provide visual separation. I do not concede that such people exist in
significant numbers. I have seen no evidence of their existence.

One could due a scientific study to test programmers speed of
comprehension (and note that this test would not be testing personal
preference. I'm fairly confident of what the results would be.

And as a final comment consider this piece of code from an actual post
to these groups many years ago:
This code will result in auto shutdown immediately after startup. Yet,
if I comment out the call to dispose(), it works fine. That makes no
sense to me because exit() should not be called without the user
calling for the frame to shut down. Why does it self-destruct?
public void processWindowEvent(WindowEvent wE) {
super.processWindowEvent(wE);
if (wE.getID() == WindowEvent.WINDOW_CLOSING)
dispose();
System.exit(0);
}

How long did it take you to find the error? There is no opening brace on
the if so what looks like the closing brace of the if is actually the
closing brace of the method. If you follow the convention that opening
braces are, without exception, on their own line the error leaps off the
page at you.
 
A

Antti S. Brax

No problem with it as long as you are following other practices that
make individual statements easy to see.
But we were discussing compound statements. The same logic does not
apply.

No problem with it as long as you are following other practices
that make individual compound statements easy to see.
 
B

Bent C Dalager

The IDE defaults are set that way for a reason, it's not just a
coincidence or following some unpopular style. K&R set their style that
way for a good reason.

It may have been a good reason at the time, but progress has caught up
with a good few of their rules.

The most obvious development is that vertical space, which used to be
very expensive, has become practically free. Back in the day, you
could expect to work on terminals with 20-25 lines on screen and this
was what you needed to base your rules on. One line saved per block of
code was significant. On today's screens, you can easily get up to 50
lines on screen and that is sufficient to do away with the old brace
style and use one that exposes code structure better.

If your methods are too long to fit on 50 lines using a modern brace
style then this means you need to refactor the method, not that there
is a problem with your brace style.
<boggle> Vertical whitespace actively interferes with reading code,
because it steals valuable vertical space. You have at least 80
columns, but at most 30-odd lines if you want them to be readable, and a
function that's more than a screen long becomes exponentially harder to
understand. This isn't exactly news, this has been known for over 30
years.

If you are using screens that are capable of 30 lines at the most,
then you might very well have a point. You should realize, however,
that many do not and I expect a majority of those that argue your
point here are among those.
You get no benefit from the vertical braces. They duplicate
information that you get from the indentation level (possibly
erroneously), and give you the opportunity to cause horrible bugs you'll
never find, because nobody who uses vertical braces uses them all the
time. With the K&R style, you can afford the screen space to always use
braces, and make safer code.

End-of-line start brace styles tend to introduce a set of complicated,
non-intuitive rules for disambiguating indentation. If it did not, you
would end up with a complete mess like this:

if (someLongExpression &&
someOtherExpression) {
doSomethingOrOther();
doSomethingMore();
}

in which it is not obvious at a glance where the if-expressions end
and where the code block begins.

In stead, there tend to be rules in place that make you write this:

if (someLongExpression &&
someOtherExpression) {
doSomethingOrOther();
doSomethingMore();
}

Or this (less used I think):

if (someLongExpression &&
someOtherExpression) {
doSomethingOrOther();
doSomethingMore();
}

There is no need for this degree of complication (I think the Sun
rules deal in indents and half-indents where one is a tab and the
other four spaces, which introduces so much trouble it would be
amusing if it weren't so tragic) when modern technology has made
vertical space conservation obsolete. In stead, you can have simple,
easy to understand, easy to read-at-a-glance indentation and brace
styles.

Cheers
Bent D
 
B

Bent C Dalager

Do you prefer

List myList = new ArrayList
(20);

to

List myList = new ArrayList(20);

In this case, that would be overemphasizing the importance of the
parameter so no. In a more complicated situation, however, I might
choose to write

LargeThingie thingie = new LargeThingie(
"A thingie",
20,
5d,
"Just another thingie",
LargeThingie.TEMPORARY);

rather than

LargeThingie thingie = new LargeThingie("A thingie", 20, 5d, "Just another thingie", LargeThingie.TEMPORARY);

or (taking into account our 80-coloumns rule)

LargeThingie thingie = new LargeThingie("A thingie", 20, 5d,
"Just another thingie", LargeThingie.TEMPORARY);

because I find the first version more readable and vertical space is
cheap.

Cheers
Bent D
 
G

George Cherry

Dale King said:
No problem with it as long as you are following other practices that make
individual statements easy to see. A single statement is a single unit.
If you do things like keep one statement per line and use visual cues to
indicate when you have to use multiple lines (e.g. indenting the rest of
the statement and separating it from surrounding statements) then there is
little information carried by the semicolon itself.

But we were discussing compound statements. The same logic does not apply.
There we have at least to parts to the statement. For example in the case
of a while you have the loop condition and you have the statements over
which you are looping. In that case there is value in making that
separation distinct. Using braces on their own lines does this very well.
It forms a visual frame around the body but is still attached to the
statement at the top to make it a cohesive unit. This is enhanced by
always using braces and add whitespace above and below to separate it from
other statements (if the thing above or below is a brace then no blank
line as the brace is already a visual separator.

A mental test I like to do is the defocus test. Consider looking at the
code but try not to focus your eyes so that you can't make out the
individual letters and see if you can get a semblance of the structure of
the code without reading the actual letters. The brace on the new line
makes it easier to see.

It seems obvious to me that you have a balanced pair of braces. Why do you
not want to keep them balanced. If Sun wanted to hide the opening brace
then they should have used something else like

if( sdfsa )
asdfas
endif



Which bears little weight with me.


The style that should be used is the one that makes code easier to read
for the largest number of readers. I and others who have posted in these
groups find that the hidden brace style is harder to read. I am willing to
concede that there are those that can read both equally. For the hidden
brace style to be the one to use there must be a significant number of
people that find it *easier* to read than using the brace to provide
visual separation. I do not concede that such people exist in significant
numbers. I have seen no evidence of their existence.

One could due a scientific study to test programmers speed of
comprehension (and note that this test would not be testing personal
preference. I'm fairly confident of what the results would be.

And as a final comment consider this piece of code from an actual post to
these groups many years ago:



How long did it take you to find the error?

About one second. I spotted it immediately.
It leaped off the page at me.
 
G

George Cherry

Bent C Dalager said:
In this case, that would be overemphasizing the importance of the
parameter so no. In a more complicated situation, however, I might
choose to write

LargeThingie thingie = new LargeThingie(
"A thingie",
20,
5d,
"Just another thingie",
LargeThingie.TEMPORARY);

rather than

LargeThingie thingie = new LargeThingie("A thingie", 20, 5d, "Just another
thingie", LargeThingie.TEMPORARY);

or (taking into account our 80-coloumns rule)

LargeThingie thingie = new LargeThingie("A thingie", 20, 5d,
"Just another thingie", LargeThingie.TEMPORARY);

because I find the first version more readable and vertical space is
cheap.

Readability is in the eye of the beholder.
BTW, I prefer

LargeThingie thingie = new LargeThingie (
"A thingie",
20,
5d,
"Just another thingie",
LargeThingie.TEMPORARY
);

Okay, I'm going to let this subject go now.
Conceit, views, and attachment are traps.
 
C

Chris Uppal

Bent said:
if (someLongExpression &&
someOtherExpression) {
doSomethingOrOther();
doSomethingMore();
}

Personally, I prefer:

if (someLongExpression
&& someOtherExpression)
{
doSomethingOrOther();
doSomethingMore();
}

In similar vein:

x = someLongExpression()
+ someOtherLongExpression()
+ SOME_CONSTANT;

I.e. not "burying" the connective operator at the end of the line.

-- chris
 
B

Bent C Dalager

Readability is in the eye of the beholder.

Our brains are very good at pattern matching so I try to make maximal
use of visual patterns in structuring the code. One parameter per
line, nicely lined up, is (I believe) a more easily spotted pattern
then a bunch of parameters placed horizontally along the line. The
one-per-line approach makes it very obvious how many parameters there
are and where each begins and ends, whileas hunting for the commas
along one long line is less immediate and you always run the risk of
having missed one.

Cheers
Bent D
 
V

Vit

Nobody in the entire world cares about your personal artistic
However people in the world do realize that making one's code
familiar-looking for anyone else is an important issue of readability.
For C++ there exist several industry standards (see the Ellemtel one
for example) that strictly perscribe where to put braces and indents
and other things like that.
Interesting just to look in - just to learn how an averaged
understanding of "what a good style of programming" is! :)

Vit
 
G

George Cherry

Bent C Dalager said:
Our brains are very good at pattern matching so I try to make maximal
use of visual patterns in structuring the code. One parameter per
line, nicely lined up, is (I believe) a more easily spotted pattern
then a bunch of parameters placed horizontally along the line. The
one-per-line approach makes it very obvious how many parameters there
are and where each begins and ends, whileas hunting for the commas
along one long line is less immediate and you always run the risk of
having missed one.

I agree--heartily.
 

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

Forum statistics

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

Latest Threads

Top