Basically, my thought was that we already had some constructs (like function bodies, or multiline if- or for- blocks) that required {}.  In some of these cases, it only inhibits clarity (IMHO) to require an extra set of {} for the try block.

Aaron wrote:

> I don't understand why people want to be able to write unclear programs so much.  What is wrong with try { }?  Really, one should have to make a good argument why NOT to force clarity, instead of having to argue for clarity in the first place.  All these "features" make compilation, analysis, and debugging harder.
>
> Aaron
>
> Pavel \"EvilOne\" Minayev wrote:
> >
> > "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3BEFE4A2.C1B4968F@deming-os.org...
> > > Along the same lines, can we remove the requirement of having {} around
> > the
> > > try blocks?  This seems reasonable to me:
> > >
> > > foo()  // note that there is no trailing semicolon
> > >     catch(ACertainException e)
> > >     {
> > >          bar();
> > >      };  // this is the closing semicolon of the expression
> >
> > I suggested a similar thing not long ago. Walter's reply wasn't that clear. =)

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Aaron" <arh14@cornell.edu> wrote in message news:3BF9131A.7AB53FBC@cornell.edu...

> I don't understand why people want to be able to write unclear programs so much.  What is wrong with try { }?  Really, one should have to make a good argument why NOT to force clarity, instead of having to argue for clarity in the first place.  All these "features" make compilation, analysis, and debugging harder.

The C way of defining a block - {} - is supposed to be used freely.
Look, if you force the {}'s, then what's the first brace is used for?
Since every if() defines a new block by your proposal, the brace
is just useless since it tells compiler of something that it's already
aware of. As such, it's a waste of time and space. On other hand,
the ending } looks quite ugly alone, so you have to replace it by
something else, like PHP alternative syntax:

    if (condition):
        statements
    endif;

There is another issue, which, BTW, was discussed before. But I'll still mention it. The else-if construct. In C, you'd write:

    if (cond1)
        ...
    else if (cond2)
        ...
    else if (cond3)
        ...
    else
        ...

Now if you require braces, you'll get:

    if (cond1)
        ...
    else { if (cond2)
        ...
    else { if (cond3)
        ...
    else {
        ...
    }}}

Now whichever you'd prefer?

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3BF92D76.86D23089@deming-os.org...

> Basically, my thought was that we already had some constructs (like
function
> bodies, or multiline if- or for- blocks) that required {}.  In some of
these
> cases, it only inhibits clarity (IMHO) to require an extra set of {} for
the
> try block.

I wouldn't mind if _multiline_ try block would require braces around it since it's the only way to tell the compiler that the block is actually multiline. =) However, when the whole block contains just a single statement, I don't understand why I have to use braces while, say, if() or for() don't require me to.

One thing we'll have to consider if try is removed is how the try block applies to loop constructs.  Consider this code:


for(int i = 0; i<10; i++)
{
   ...
}
catch(ExceptionFoo f)
{
  ....
}



Now, does the catch catch just one iteration of the loop, or the whole thing? That is, is it equivalent to:

{
    for(...)
    {
        ...
     }
}
catch(...)
{
   ...
};


or is it:

for( ... )
{
    {
         ...
    }
    catch( ... )
    {
         ...
    }
}


I would tend to lean toward the latter....but is it obvious to an inexperienced reader or coder?


Pavel Minayev wrote:

> I wouldn't mind if _multiline_ try block would require braces around it since it's the only way to tell the compiler that the block is actually multiline. =) However, when the whole block contains just a single statement, I don't understand why I have to use braces while, say, if() or for() don't require me to.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

> There is another issue, which, BTW, was discussed before. But I'll still mention it. The else-if construct. In C, you'd write:
>
>     if (cond1)
>         ...
>     else if (cond2)
>         ...
>     else if (cond3)
>         ...
>     else
>         ...
>
> Now if you require braces, you'll get:
>
>     if (cond1)
>         ...
>     else { if (cond2)
>         ...
>     else { if (cond3)
>         ...
>     else {
>         ...
>     }}}
>
> Now whichever you'd prefer?

If the language merely treated "else if" as a special case, that wouldn't be a problem.

Sean

My final point:

If you think that braces make source code cleaner, then
use them in your programs. But don't force others to.
Let it be freedom of choice. I, personally, think that
small ifs without {}s look neater:

    if (health <= 0)
        Die();
    else
        Sound(painsound);

    --- vs ---

    if (health <= 0)
    {
        Die();
    }
    else
    {
        Sound(painsound);
    }

Pavel Minayev wrote:
> 
> My final point:
> 
> If you think that braces make source code cleaner, then
> use them in your programs. But don't force others to.
> Let it be freedom of choice. I, personally, think that
> small ifs without {}s look neater: (snip)

It's not about how things look; it's about adding the line:

>     if (health <= 0)
>         Die();
>     else

          printf("Some debugging information to explain why the Sound() call isn't working god damn it\n" );

>         Sound(painsound);

...at 1 in the morning...

...on Sunday night...

...before the beta deadline on Monday...

...after 5 weeks of crunch time...

...while listening to a junior programmer who shares your office trying to explain _his_ bug to you...

...and trying to ignore the head of product development asking you how that sound bug's coming along.

Sure, only an idiot would forget to add the braces when adding another statement to an else clause. Under those and similar conditions, however, I'm an idiot.

-RB

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3BFAA487.65459F63@estarcion.com...

> Sure, only an idiot would forget to add the braces when
> adding another statement to an else clause. Under those
> and similar conditions, however, I'm an idiot.

First, you aren't =) So there must be something wrong
with the conditions.

Second, what's the problem anyhow? Just consider always
putting {}'s around blocks in _your_ programs a rule.
There is no need for compiler to enforce this.

Pavel Minayev wrote:
> 
> "Russell Borogove" <kaleja@estarcion.com> wrote in message news:3BFAA487.65459F63@estarcion.com...
> 
> > Sure, only an idiot would forget to add the braces when
> > adding another statement to an else clause. Under those
> > and similar conditions, however, I'm an idiot.
> 
> First, you aren't =) So there must be something wrong
> with the conditions.

Yes, definitely, there's something wrong with the conditions...

> Second, what's the problem anyhow? Just consider always
> putting {}'s around blocks in _your_ programs a rule.
> There is no need for compiler to enforce this.

Yes; the fact that some of my coworkers don't {} consistently is another thing wrong with the conditions here, not a problem with C per se.

-RB

"Pavel Minayev" <evilone@omen.ru> wrote in news:9tbd08$205u$1@digitaldaemon.com...
>
> The C way of defining a block - {} - is supposed to be used freely.
> Look, if you force the {}'s, then what's the first brace is used for?
> Since every if() defines a new block by your proposal, the brace
> is just useless since it tells compiler of something that it's already
> aware of. As such, it's a waste of time and space. On other hand,
> the ending } looks quite ugly alone, so you have to replace it by
> something else, like PHP alternative syntax:
>
>     if (condition):
>         statements
>     endif;

<irony on>

Looking by this side, in the 'if' above what's the first parenthesis is used
for?
Since every 'if' defines a condition the parenthesis is just useless since
it tells
compiler of something that it's already aware of. As such, it's a waste of
time
and space. Look:

   if condition)
       statement

On other hand  the ending ) looks quite ugly alone, so you have to replace
it by
something else, like 'then':

  if condition then
      statement

<irony off>

I disagree with this.
Forcing braces means clearer code, and looks nicer, as already has been done
for
conditions in C.

Ciao.