Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Why braces around try/catch?

Reply
Thread Tools

Why braces around try/catch?

 
 
Thomas G. Marshall
Guest
Posts: n/a
 
      08-06-2003
Jacob <(E-Mail Removed)> horrified us with:

> Tor Iver Wilhelmsen wrote:
>> "Henrik S. Hansen" <(E-Mail Removed)> writes:
>>
>>
>>> 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?

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


In 20+ years of C and Java, I don't think I have either, and with WITHOUT
syntax/grammer help.

But here's the point: Even if I had made that error, say, 5 times. It's
hardly an issue to give up the improved readability for.




 
Reply With Quote
 
 
 
 
Virgil Green
Guest
Posts: n/a
 
      08-06-2003
"Jacob" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Tor Iver Wilhelmsen wrote:
> > "Henrik S. Hansen" <(E-Mail Removed)> writes:
> >
> >
> >>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?

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


So, does this mean that you *have* made the error but immediately corrected
it because your editor made it readily apparent?

- Virgil


 
Reply With Quote
 
 
 
 
Bent C Dalager
Guest
Posts: n/a
 
      08-06-2003
In article <(E-Mail Removed)>,
Chris Smith <(E-Mail Removed)> wrote:
>There's no doubt that things like:
>
> if (a)
> b;
> c;
>
>fall into the clever classroom bugs category.


I have seen this bug in production code, and it can be quite
insidious. I only trapped it because I started wondering why the
debugger was jumping around in such a non-conventional manner

It wasn't even the bug I was looking for (or so it told me, and waved
its hand ... hmmm). In stead, it was a latent bug that would show up
one time out of a million and do something slightly wrong. But not
sufficiently wrong that anyone had cried up about it. Yet.

Cheers
Bent D
--
Bent Dalager - http://www.velocityreviews.com/forums/(E-Mail Removed) - http://www.pvv.org/~bcd
powered by emacs
 
Reply With Quote
 
Miguel De Anda
Guest
Posts: n/a
 
      08-06-2003

"Henrik S. Hansen" <(E-Mail Removed)> wrote in message
news:bgpmaa$1in7$(E-Mail Removed)...
> 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.
>
> --
> Henrik S. Hansen
>


I think it's to annoy people who don't handle errors.

If braces were not required, people would often be tempted to write code
like this:

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

Or better yet:

try dangerMethod(); catch(Exception gripe);

Which would be similar to:

for(int i=0; i<5; i++);

And simply ignore the exception. There is already too much code with:

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

And I believe that the java people knew this would happen and simply made it
required to remind people to put something in there.


 
Reply With Quote
 
Thomas G. Marshall
Guest
Posts: n/a
 
      08-06-2003
Tor Iver Wilhelmsen <(E-Mail Removed)> horrified us with:

> "Thomas G. Marshall"
> <(E-Mail Removed). com> writes:
>
>> But here's the point: Even if I had made that error, say, 5 times.
>> It's hardly an issue to give up the improved readability for.

>
> So would you want the same in *every* situation where there is only
> one statement in a block? e.g.
>
> public int getFoo() return 42;
>
> for instance? The parser can easily handle that, too.
>
> The problem with allowing brace-less single-statement-ifs and the like
> is that you then have two syntaxes for essentially the same thing: One
> with, and one without the braces, the difference being the number of
> statements (0-1 vs. 0-n). In the compiled code, there IS no semantic
> difference - a branch does not care how many statements it skips. Why
> should the language differentiate?


Using your logic there shouldn't be any literals per se. Everything should
be single element arrays for literals.

int[] a = {1};
a[0]++;

In the case of a single element, the compiler CERTAINLY knows not to use
index code unecessasrily.

So your words apply: "Why should the language differentiate?"

The answer is that there is /no/ reason for a language to be consistant to
the extent that readability suffers.

You need only one of while, for, do loops, so why all three?

Readability. And readability over the lifecycle of a product directly
influences maintainability.


 
Reply With Quote
 
Tor Iver Wilhelmsen
Guest
Posts: n/a
 
      08-06-2003
"Thomas G. Marshall" <(E-Mail Removed). com> writes:

> But here's the point: Even if I had made that error, say, 5 times.
> It's hardly an issue to give up the improved readability for.


So would you want the same in *every* situation where there is only
one statement in a block? e.g.

public int getFoo() return 42;

for instance? The parser can easily handle that, too.

The problem with allowing brace-less single-statement-ifs and the like
is that you then have two syntaxes for essentially the same thing: One
with, and one without the braces, the difference being the number of
statements (0-1 vs. 0-n). In the compiled code, there IS no semantic
difference - a branch does not care how many statements it skips. Why
should the language differentiate?

In the try/catch/finally case, braces could be "inferred" for all
blocks except the last catch or the finally, because catch and finally
are single-use keywords. But would anyone want to add such complexity
to the compiler to save those few keystrokes?
 
Reply With Quote
 
George W. Cherry
Guest
Posts: n/a
 
      08-06-2003

"Henrik S. Hansen" <(E-Mail Removed)> wrote in message
news:bgpmaa$1in7$(E-Mail Removed)...
> 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.
>
> --
> Henrik S. Hansen


Let me change the question around: why not mandatory
block, {}, in

if (boolean-expression) { doSomething(); }

and

do {
statement or statements
} while (boolean-expression);

and so on? I do this anyway.

George


 
Reply With Quote
 
Thomas G. Marshall
Guest
Posts: n/a
 
      08-06-2003
Bent C Dalager <(E-Mail Removed)> horrified us with:

> In article <(E-Mail Removed)>,
> Chris Smith <(E-Mail Removed)> wrote:
>> There's no doubt that things like:
>>
>> if (a)
>> b;
>> c;
>>
>> fall into the clever classroom bugs category.

>
> I have seen this bug in production code, and it can be quite
> insidious. I only trapped it because I started wondering why the
> debugger was jumping around in such a non-conventional manner
>
> It wasn't even the bug I was looking for (or so it told me, and waved
> its hand ... hmmm). In stead, it was a latent bug that would show up
> one time out of a million and do something slightly wrong. But not
> sufficiently wrong that anyone had cried up about it. Yet.


Yeah, but that's not enough.

A language cannot attempt to solve all manner of bugs at the price of lost
readability.

Here's a bug too:

a = a++;

I've seen that from time to time in C land (ages ago), and I hardly ever saw
compilers even warn about that. Should that necessitate the abolishion of
the unary ++ operator?

You have to draw the line somewhere. I like where Java's drawn that line.
No MI. Labeled (downward) break (goto). So far so good, but I'm worried
about the future. For example, I'm holding my breath that the
auto-boxing/unboxing of primitives in 1.5 doesn't swim up and bite us all in
the ass.


 
Reply With Quote
 
Chris Smith
Guest
Posts: n/a
 
      08-07-2003
Bent C Dalager wrote:
> I have seen this bug in production code, and it can be quite
> insidious. I only trapped it because I started wondering why the
> debugger was jumping around in such a non-conventional manner


Really, though, you have to ask yourself a very important question: if
someone doesn't have the basic understanding of the language to avoid
this, is their code worth using anyway. If it weren't for office-
political considerations, programmers who lack such basic understanding
of the language they are working in should be asked to stay home for the
good of the project. They certainly can't be trusted to be diligent
about introducing really difficult bugs.

Real bugs introduced by competent programmers have to do with making
wrong assumptions about code that's being written, not failing to
understand a basic point of language syntax. No language feature in the
world could have prevented the programmer in question from introducing
some kind of bug that ost you that productivity.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
Reply With Quote
 
Chris Smith
Guest
Posts: n/a
 
      08-07-2003
Shripathi Kamath wrote:
> "Jacob" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > Shripathi Kamath wrote:
> >
> > > try
> > > statement1;
> > > statementx;
> > > catch (Exception e)
> > > statement2;
> > > statementy;

> >
> > This whould be a syntax error equivalent to:
> >
> > if (clause)
> > statement1;
> > statement2;
> > else
> > statements;
> >

>
> But only if you assume the try and if to be similar in all respects with
> respect to the single statement.
>
> A try must be followed by a catch, an if has no such restrictions.
>
> In that sense, it is more along the lines of a do { ...} while (...);
> statement.
>
> I think that try { .. } catch(...) {}... is best compared to that.


Okay, fine. So it's a syntax error equivalent to:

do
statement1;
statement2;
while (...);

So while you managed to point out one possible difference between if and
try, it was not relevant to what was being discussed.

Besides which, a try does not need to be followed by a catch. It needs
to be followed by one or more catch blocks and/or exactly one finally
block.

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

>
> If the constructs were similar, perhaps yes. If they are not, it cannot be.
> An if may have a else clause, whereas a try must. It is not reasonable to
> expect the two to have identical syntax.


Whether "identical" is the right word, it does make sense to build the
entire language upon one set of syntactical onstructs. To require a
compound statement in some places while allowing either type of
statement in others is a needless complication of the language, and is
really somewhat pointless. So I agree that either form should be usable
in either case.

I also think ANYTHING that makes small try blocks less syntactically
intrusive is a good thing. As it is, programmers write horrible code
just because better code is really ugly.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
warning: missing braces around initializer Pawel C++ 13 11-14-2008 12:08 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
allowing braces around suites Kjetil Torgrim Homme Python 99 09-08-2004 06:13 AM
Re: allowing braces around suites Michael Sparks Python 1 08-31-2004 02:43 AM
RE: allowing braces around suites Delaney, Timothy C (Timothy) Python 2 08-30-2004 03:39 PM



Advertisments