Why braces around try/catch?

[Henrik S. Hansen]

Does anyone know why braces are required around a try/catch block of
code? It seems counter-intuitive, since if/else etc. accept a single
statement without braces.

 

[Thomas G. Marshall]

Does anyone know why braces are required around a try/catch block of
code? It seems counter-intuitive, since if/else etc. accept a single
statement without braces.

Ironically, I was just thinking about this the other day. I was musing
about simple uses like:

try {dangerMethod();} catch(Exception ignore){}

would be better as

try dangerMethod() IgnoreException; (new keyword)

But I was also wondering, as you are, about the simple but not allowed

try dangerMethod(); catch(Exception gripe) someStatement;

The conclusion I came to was that the try and catch are part of the same
construct. Unlike "else", a "catch" is mandatory. So perhaps they don't
want a statement terminator ( inbetween?

Not sure. Perhaps there is a parse-level reason for that.

 

[Roedy Green]

Does anyone know why braces are required around a try/catch block of
code? It seems counter-intuitive, since if/else etc. accept a single
statement without braces.

It is probably because try catch are usually used over many lines of
code. For the few times you use over just one line, it would be
confusing. People would be expecting the {} to read.

 

[Shripathi Kamath]

Does anyone know why braces are required around a try/catch block of
code? It seems counter-intuitive, since if/else etc. accept a single
statement without braces.

Pure speculation, and soapbox material:


Consider a single line if statement:

if (booleanexpression) statement1;

Equivalently, it can be written as

if (booleanexpression)
statement1;

Let us assume that the above is intuitive

if (booleanexpression)
statement1;
statement2;

is still valid, although it may not be what you intended.


Now carry over the same intuition to try and catch

If single statements were allowed

try
statement1;
catch (Exception e)
statement2;

should be intuitive

How about:

try
statement1;
statementx;
catch (Exception e)
statement2;
statementy;

Is statementy part of the catch? Intuitively? How about statementx being
part of the try? legal? intuitive? are the rules different for try and
catch?

Try nesting them


try
statement1;
statementx;
try
statement1a;
statementxa;
catch (Exception e)
statement2;
statementy;
statementz;
catch (Exception e)
statement2b;
statementyb;

Is statementz part of the catch or the outer try? if and else structures
with single statements have less or no ambiguity imho.

 

[Jacob]

try
statement1;
statementx;
catch (Exception e)
statement2;
statementy;

This whould be a syntax error equivalent to:

if (clause)
statement1;
statement2;
else
statements;

BTW: This topic was discussed awhile ago (with me
as the OP), and there was no clear conclusion why
you need braces around single statement try-catch
or methods.

The gereral opinion (of style) is that you should
not utilize the possibility to omit braces where
this is indeed possible (of which I disagree).

I think that the language whould be simpler if the
syntax was identical in all cases.

 

[Jacob]

It is probably because try catch are usually used over many lines of
code. For the few times you use over just one line, it would be
confusing. People would be expecting the {} to read.

I find it hard to believe that James Gosling & Co. back in
the early 90's actually considered how many lines of code
they believed people would put within a try statement and
concluded "many" so they forced braces on the construct.

As a matter of style I actually put as little code as
possible within a try block in order to better indicate
where exactly an exception may occour. And from my
experience, a catch block very often is a one-liner.

 

[Jacob]

Ironically, I was just thinking about this the other day. I was musing
about simple uses like:

try {dangerMethod();} catch(Exception ignore){}

would be better as

try dangerMethod() IgnoreException; (new keyword)

But I was also wondering, as you are, about the simple but not allowed

try dangerMethod(); catch(Exception gripe) someStatement;

The conclusion I came to was that the try and catch are part of the same
construct. Unlike "else", a "catch" is mandatory. So perhaps they don't
want a statement terminator ( inbetween?

Possibly. But for a do-statement, the while is mandatory,
but the braces are not:

do
statement;
while (clause);

 

[Tor Iver Wilhelmsen]

Does anyone know why braces are required around a try/catch block of
code? It seems counter-intuitive, since if/else etc. accept a single
statement without braces.

Actually the real problem is the reverse case: Why does if, for, do
and while *bug-inducingly* allow single statements? The first edition
of Java in a Nutshell used try/catch examples without braces, so it
seems it was so at one point (pre-1.0.2).

They really should amend the language the other way, and force use of
braces for if, for, do and while as well as for the current switch,
synchronized, try, cath, finally, method declarations, etc.

 

[Lee Fesperman]

Actually the real problem is the reverse case: Why does if, for, do
and while *bug-inducingly* allow single statements? The first edition
of Java in a Nutshell used try/catch examples without braces, so it
seems it was so at one point (pre-1.0.2).

They really should amend the language the other way, and force use of
braces for if, for, do and while as well as for the current switch,
synchronized, try, cath, finally, method declarations, etc.

My explanation is that the language designers allowed braceless if, for, etc. simply for
compatiblity with C/C++. For Java only constructs, they went with their preferences,
which were to require braces.

In that past, I have moved simple C functions directly to Java by adding public. So, I
found it convenient.

I'd never considered a braceless switch before. Here's one that actually does something:

switch (character)
case '\n' :
continue;

.... ;^)

 

[Henrik S. Hansen]

They really should amend the language the other way, and force use of
braces for if, for, do and while as well as for the current switch,
synchronized, try, cath, finally, method declarations, etc.

I disagree strongly. Why on earth should you introduce redundant
syntax? Single-line if statements are easy to read, and never confusing
in my experience.

Java is already pretty bondage-and-discipline, why make it worse?

 

[Tor Iver Wilhelmsen]

I'd never considered a braceless switch before. Here's one that
actually does something:

switch (character)
case '\n' :
continue;

Or a braceless method declaration, e.g.

public String getValue()
return value;

I say either make them mandatory like in Perl, or drop them like in
Python.

 

[Tor Iver Wilhelmsen]

I disagree strongly. Why on earth should you introduce redundant
syntax? Single-line if statements are easy to read, and never
confusing in my experience.

You say that you NEVER have made the error of adding another statement
to an if block without noticing that there was no "block" there? Is
the effort of adding those two characters really such an effort that
the potential bugs induced by their absence are worth it?

Single-line if statements are no more easy to read than multiline
if-statements.

 

[Jacob]

You say that you NEVER have made the error of adding another statement
to an if block without noticing that there was no "block" there?

In 15 years of C++ and Java I have never made
such an error. My editor (emacs) will reindent
code immediately, and the lack of braces whould
become immediately apparent.

Other people working with my code *might* have
made such an error of course (by the use of less
capable editors), but I don't think this is a
common source of errors.

 

[Larry A Barowski]

Does anyone know why braces are required around a try/catch block of
code? It seems counter-intuitive, since if/else etc. accept a single
statement without braces.

I answered this here a few months ago, like this:

if-else ambiguity is the only real problem with single
statements in other structures, and the resolution (else belongs
to innermost if) is easy to understand for the coder, and easily
implemented in an S-R parser (usually "shift" is the default for
an S-R conflict, or you can grammar your way around it as in the
NoShortIf productions in the Java LRM).

try-catch ambiguity would be much more of a mess because of the
multiple "catch"es. If all "catch"es belong to the innermost "try"
and there is no "finally", then braces would always be required on
the innermost "try" anyway (since a "catch" or "finally" is
required on the outermost "try"), otherwise there is no way to
tell where the "catch"es for the innermost "try" end. But no
braces would be required in the case where a "finally" was in
the middle of a sequence of "try"s. Trying to parse that would
be a real pain.


-Larry

 

[Thomas G. Marshall]

Sure. Is there any good reason you shoudn't?



No problem. (Though from a readability point of
view, I'd might have organized it differently.
This has nothing to do with the lack of braces
however.)

Hmmmm....

public class HelloWorld public static void main(String[]args)
System.out.println("gross!");

OI.

 

[Thomas G. Marshall]

I find it hard to believe that James Gosling & Co. back in
the early 90's actually considered how many lines of code
they believed people would put within a try statement and
concluded "many" so they forced braces on the construct.

As a matter of style I actually put as little code as
possible within a try block in order to better indicate
where exactly an exception may occour. And from my
experience, a catch block very often is a one-liner.

That's not a matter of /style/. That's in the category of a good
programming technique.

 

[Thomas G. Marshall]

Pure speculation, and soapbox material:


Consider a single line if statement:

if (booleanexpression) statement1;

Equivalently, it can be written as

if (booleanexpression)
statement1;

Let us assume that the above is intuitive

if (booleanexpression)
statement1;
statement2;

is still valid, although it may not be what you intended.

Python.

 

[Thomas G. Marshall]

Actually the real problem is the reverse case: Why does if, for, do
and while *bug-inducingly* allow single statements?

"bug-inducingly" is not a toggle. There are shades of gray.

When determining if something is bug promoting, you have to first evaluate
the degree to which it is likely to cause a problem.

Unlike willynilly goto's, for example, I see no compelling reason to require
braces for single statements. The gain in readability is evident to me.

 

[Thomas G. Marshall]

I disagree strongly. Why on earth should you introduce redundant
syntax? Single-line if statements are easy to read, and never
confusing in my experience.

I agree.

Java is already pretty bondage-and-discipline, why make it worse?

.....except that I would argue strongly that the beauty of java is not the
W1RA, but the wonderful golden handcuffs it places on the junior engineers
in your team.

But, again, you have to weigh the impacts. I just don't see single line
statements as being a source of bugs, or bad programming design.

 

[Thomas G. Marshall]

You say that you NEVER have made the error of adding another statement
to an if block without noticing that there was no "block" there? Is
the effort of adding those two characters really such an effort that
the potential bugs induced by their absence are worth it?

Single-line if statements are no more easy to read than multiline
if-statements.

Yes they are. Code is obfuscated /enough/ with braces all over creation.

And, sure, such multi line things happen, but /rarely/ in my experience.