What was the rationale behind requiring the bodies of try and catch to
be blocks instead of statements (possibly compound)? It seems
inconsistent with other similar constructs such as if / else. Why not
allow

   try
      <stmt1>
   catch (std::exception&)
      <stmt2>

where <stmt2> and <stmt2> could be either simple or compound (with
braces) exactly as if / else?

Thanks

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Thursday 04 March 2004 05:51 pm, Gregg wrote:

> What was the rationale behind requiring the bodies of try and catch to
> be blocks instead of statements (possibly compound)?

You need the braces to tell which catch goes with which try.
For example:

try
try
  try_this();
catch (exception1&)
  handle1();
catch (exception2&)
  handle2();
catch (exception3&)
  handle3();
--
Ray Lischner, author of C++ in a Nutshell
http://www.tempest-sw.com/cpp

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

rl.news@tempest-sw.com (Ray Lischner) wrote in message news:<1785.4047f27d.858ca@prospero.island.local>...
> On Thursday 04 March 2004 05:51 pm, Gregg wrote:
>
> > What was the rationale behind requiring the bodies of try and catch to
> > be blocks instead of statements (possibly compound)?
>
> You need the braces to tell which catch goes with which try.
> For example:
>
> try
> try
>   try_this();
> catch (exception1&)
>   handle1();
> catch (exception2&)
>   handle2();
> catch (exception3&)
>   handle3();

I'm not convinced this is the only reason, because it would have been
just as reasonable to stipulate that catch'es go with the closest try,
as it happens with else's and if's. If this were the case, the example
above would result in a "try without catch" error.

Cheers,
Nicola Musatti

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

rl.news@tempest-sw.com (Ray Lischner) wrote in message news:<1785.4047f27d.858ca@prospero.island.local>...
> On Thursday 04 March 2004 05:51 pm, Gregg wrote:
>
> > What was the rationale behind requiring the bodies of try and catch to
> > be blocks instead of statements (possibly compound)?
>
> You need the braces to tell which catch goes with which try.
> For example:
>
> try
> try
>   try_this();
> catch (exception1&)
>   handle1();
> catch (exception2&)
>   handle2();
> catch (exception3&)
>   handle3();

I personally don't find this a compelling argument.  You run into a
similar situation with if statements:

if (this)
  if (that)
else
 ....

and one just knows that if you are going to nest, then you must use
braces.  The same rules could apply here.  I am not really advocating
a change, but there really should be a better rationale than that.

joe

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Friday 05 March 2004 10:04 am, Nicola Musatti wrote:

> I'm not convinced this is the only reason, because it would have been
> just as reasonable to stipulate that catch'es go with the closest try,
> as it happens with else's and if's. If this were the case, the example
> above would result in a "try without catch" error.

The difference is that try can have mutliple catch parts. An if
statement can have only one else part.
--
Ray Lischner, author of C++ in a Nutshell
http://www.tempest-sw.com/cpp

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Ray Lischner" <rl.news@tempest-sw.com> wrote in message
news:441a.40489af6.9d911@prospero.island.local...
> On Friday 05 March 2004 10:04 am, Nicola Musatti wrote:
>
> > I'm not convinced this is the only reason, because it would have been
> > just as reasonable to stipulate that catch'es go with the closest try,
> > as it happens with else's and if's. If this were the case, the example
> > above would result in a "try without catch" error.
>
> The difference is that try can have mutliple catch parts. An if
> statement can have only one else part.

True, but there *still* could be a simple disambiguation rule
for catch clauses. Each could bind to the immediately preceding
try clause. But the whole discussion is academic because that's
now the grammar that was chosen, for whatever reason.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Slightly differently
Why no finally which gets executed whether try or catch happens.  Ie, code
that always runs before a function ends?

As a Java programmer I find it useful at times.

Tony

On Fri, 05 Mar 2004
15:35:01 +0000, Ray Lischner wrote:

> On Friday 05 March 2004 10:04 am, Nicola Musatti wrote:
>
>> I'm not convinced this is the only reason, because it would have been
>> just as reasonable to stipulate that catch'es go with the closest try,
>> as it happens with else's and if's. If this were the case, the example
>> above would result in a "try without catch" error.
>
> The difference is that try can have mutliple catch parts. An if
> statement can have only one else part.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

rl.news@tempest-sw.com (Ray Lischner) wrote in message news:<1785.4047f27d.858ca@prospero.island.local>...

> You need the braces to tell which catch goes with which try.

I hadn't considered the case of nested handlers with multipe catch
clauses, and it seems obvious now that that was the reason for
requiring the braces. However, it still strikes me as an ugly
linguistic inconsistency.  It seems that it would have been better to
apply rules similar to those for disambiguating nested if/else
statements, extended to handle mulitple catch clauses.

Gregg

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

gregglastname@hotmail.com (Gregg) wrote in message news:<20d0a2b2.0403041413.13e57e69@posting.google.com>...
> What was the rationale behind requiring the bodies of try and catch to
> be blocks instead of statements

Perhaps blocks are required to avoid a gratuitous difference with
function definitions ;-)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

It was an arbitrary decision. Bjarne considered allowing the braces
to be absent but decided it would be safer to insist on them. (I
think this is mentioned in "The Design and Evolution of C++", along
with the point that, strictly speaking, the "try" is redundant too.)

As for why the standard kept the rule rather than making it
consistent with other parts of the language, I can only guess,
but I would guess that the suggestion never came up. "try" and
"catch" are suffiently rare in real programs that it probably
doesn't matter.

"Gregg" <gregglastname@hotmail.com> wrote...
> What was the rationale behind requiring the bodies of try and catch to
> be blocks instead of statements (possibly compound)? It seems
> inconsistent with other similar constructs such as if / else.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Tony Burrows wrote:
> Slightly differently
> Why no finally which gets executed whether try or catch happens.  Ie,
> code that always runs before a function ends?
>
> As a Java programmer I find it useful at times.

Java needs it because it has no deterministic destruction of objects. Java
programmers have to make sure they manually release resources whereas C++
programmers don't have to worry about this at all. That is why a 'finally'
has much less importance in C++ than it does in Java ( or C# ). So C++ never
adopted such a measure, and I don't believe it needs it. A number of C++
compiler implementations have added it as an extension to C++.

>
> Tony
>
> On Fri, 05 Mar 2004
> 15:35:01 +0000, Ray Lischner wrote:
>
>> On Friday 05 March 2004 10:04 am, Nicola Musatti wrote:
>>
>>> I'm not convinced this is the only reason, because it would have
>>> been just as reasonable to stipulate that catch'es go with the
>>> closest try, as it happens with else's and if's. If this were the
>>> case, the example above would result in a "try without catch" error.
>>
>> The difference is that try can have mutliple catch parts. An if
>> statement can have only one else part.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""P.J. Plauger"" <pjp@dinkumware.com> wrote in message
news:RO22c.65045$C65.38591@nwrddc01.gnilink.net...

> True, but there *still* could be a simple disambiguation rule
> for catch clauses. Each could bind to the immediately preceding
> try clause.

Unfortunately, that rule does the wrong thing for the following case:

    try f(); try g(); catch(...) x(); catch(...) y();

Because each try must have at least one catch, there is only one sensible
way to parse this example:  The first catch must go with the second try, and
the second catch must go with the first try.  If each catch binds to the
immediately preceding try, then the first try winds up without a
corresponding catch.

So I think a disambiguation rule would have to be more complicated to be
useful.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Andrew Koenig"" <ark@acm.org> wrote in message
news:oIp2c.80412$aH3.2458080@bgtnsc04-news.ops.worldnet.att.net...
> ""P.J. Plauger"" <pjp@dinkumware.com> wrote in message
> news:RO22c.65045$C65.38591@nwrddc01.gnilink.net...
>
> > True, but there *still* could be a simple disambiguation rule
> > for catch clauses. Each could bind to the immediately preceding
> > try clause.
>
> Unfortunately, that rule does the wrong thing for the following case:
>
>     try f(); try g(); catch(...) x(); catch(...) y();
>
> Because each try must have at least one catch, there is only one sensible
> way to parse this example:  The first catch must go with the second try,
and
> the second catch must go with the first try.  If each catch binds to the
> immediately preceding try, then the first try winds up without a
> corresponding catch.
>
> So I think a disambiguation rule would have to be more complicated to be
> useful.

Agreed, but there are other simple rules in C/C++ that don't always give
the "useful" result, such as x+++++y. Yet we've kept them for simplicity,
in some dimension.

This quibble doesn't alter the fact that it was probably wise to require
compound statements after try and catch.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

tony@tonyburrows.com (Tony Burrows) wrote in message news:<pan.2004.03.05.17.10.05.427664@tonyburrows.com>...
> Slightly differently
> Why no finally which gets executed whether try or catch happens.  Ie, code
> that always runs before a function ends?
>
> As a Java programmer I find it useful at times.
>
> Tony
>

Because in C++, stack based objects get destroyed deterministically.
Whatever you would put into a finally block, just put into the
destructor of a stack based object.

Now, you might say that writing stack based objects just to have
specialized destructors is a pain, and you'd be correct.  Enter
ScopeGuard, C++'s finally!

http://www.cuj.com/documents/s=8000/cujcexp1812alexandr/alexandr.htm
http://tinyurl.com/26vzp

ScopeGuard lets you create stack-based object's, on the fly, who's
destructor does whatever you want:

FILE *pFile = FOPEN(...);
ON_BLOCK_EXIT(fclose,pFile);

-joshua lehrer
factset research systems
NYSE:FDS

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> Why not allow
>
>    try
>       <stmt1>
>    catch (std::exception&)
>       <stmt2>
>
> where <stmt2> and <stmt2> could be either simple or compound (with
> braces) exactly as if / else?

There can be many catch() statements associated with each try:

try {
} catch (std::exception const &) {
} catch (...) {
}

and trys can be nested

try {
  try {
  } catch (std::exception const &) {
    // handle known exception and absorb it
  } catch (...) {
    // report unknown exception and rethrow
    ...
    throw;
  }
} catch (...) {
  // handle the unknown exception at an outer scope
}

Now, if the curlies were removed, this becomes
try // (1)
  try // (2)
    <stmt1>
  catch (std::exception const &)
    <stmt2>
  catch (...) // (3)
    <stmt3>
catch (...)  // (4) -- ambigous
    <stmt4>

The catch(...) at (4) has lost context, and will look as though it belongs
to try (2), but has already been defined at (3). This is different to the
if..else example you cited, as each 'if' can have zero or one else clauses,
but try can have one or more catch-s.

-- Craig


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>>You need the braces to tell which catch goes with which try.
>>For example:
>>
>>try
>>try
>>  try_this();
>>catch (exception1&)
>>  handle1();
>>catch (exception2&)
>>  handle2();
>>catch (exception3&)
>>  handle3();
>
>
> I personally don't find this a compelling argument.  You run into a
> similar situation with if statements:
>
> if (this)
>   if (that)
> else
>  ....
>
> and one just knows that if you are going to nest, then you must use
> braces.  The same rules could apply here.  I am not really advocating
> a change, but there really should be a better rationale than that.

Additionally, this situation doesn't seem likely to occur in real code
that much.  If there really is a try nested directly in another try, the
outer try seems to me to be completely redundant.  Regardless of how you
group the trys with the catches above (unless you interpret it as a
syntax error), it seems like you could have gotten the exact same effect
by doing:

try
   try_this();
catch (exception1&)
   handle1();
catch (exception2&)
   handle2();
catch (exception3&)
   handle3();

If the effects aren't the same, it seems to me that they're close enough
that there's no demand for nesting one try as the only body to another try.

(Nesting a try as the only body of another catch might create some
ambiguity, OTOH.  But there the "bind with the closest try" type rule
seems reasonable if you want to allow non-compound statements as try or
catch clauses.)


Adam H. Peterson

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 5 Mar 2004 15:04:24 +0000 (UTC), Nicola.Musatti@ObjectWay.it
(Nicola Musatti) wrote:

>I'm not convinced this is the only reason, because it would have been
>just as reasonable to stipulate that catch'es go with the closest try,
>as it happens with else's and if's.

Yes. See indeed

http://groups.google.com/groups?threadm=FpxFGJ.Hor%40research.att.com

I also remember having read somewhere that the issue was discussed
within the committee and that it wasn't considered worth adding
another special rule (though it would have been a "familiar" special
rule for its similarity with the if-else case).


--
Genny.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gregg wrote:
> What was the rationale behind requiring the bodies of try and catch to
> be blocks instead of statements (possibly compound)? It seems
> inconsistent with other similar constructs such as if / else. Why not
> allow
>
>    try
>       <stmt1>
>    catch (std::exception&)
>       <stmt2>
>
> where <stmt2> and <stmt2> could be either simple or compound (with
> braces) exactly as if / else?

Quoting from "The Design and Evolution of C++", pg. 386 (which should be
the first place one looks for answers to questions like this):

"The try keyword is completely redundant and so are the { } brackets
except where multiple statements are actually used in a try-block or a
handle.  For example, it would have been trivial to allow:

 int f()
 {
  return g() catch (xxii) { // not C++
   error("g() goofed: xxii");
   return 22;
  };
 }

However, I found this so difficult to explain that the redundancy was
introduced to save support staff from confused users."

--
David Olsen
qg4h9ykc5m@yahoo.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Nicola Musatti" <Nicola.Musatti@ObjectWay.it> wrote in message
news:a327cf48.0403050513.458c6946@posting.google.com...
> rl.news@tempest-sw.com (Ray Lischner) wrote in message
news:<1785.4047f27d.858ca@prospero.island.local>...

> > You need the braces to tell which catch goes with which try.
> > For example:
> >
> > try
> > try
> >   try_this();
> > catch (exception1&)
> >   handle1();
> > catch (exception2&)
> >   handle2();
> > catch (exception3&)
> >   handle3();

> I'm not convinced this is the only reason, because it would have been
> just as reasonable to stipulate that catch'es go with the closest try,
> as it happens with else's and if's. If this were the case, the example
> above would result in a "try without catch" error.

Not really, because each try must have at least one catch.  So although the
"each catch goes with the closest try" rule is simple, it would fail for
cases such as

    try ... try ... catch ... catch

where there is only one possible interpretation.

It's easier to require programmers to be explicit.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Tony Burrows wrote:
> Slightly differently
> Why no finally which gets executed whether try or catch happens.  Ie,
> code that always runs before a function ends?
>
> As a Java programmer I find it useful at times.

Java needs it because it has no deterministic destruction of objects. Java
programmers have to make sure they manually release resources whereas C++
programmers don't have to worry about this at all. That is why a 'finally'
has much less importance in C++ than it does in Java ( or C# ). So C++ never
adopted such a measure, and I don't believe it needs it. A number of C++
compiler implementations have added it as an extension to C++.

>
> Tony
>
> On Fri, 05 Mar 2004
> 15:35:01 +0000, Ray Lischner wrote:
>
>> On Friday 05 March 2004 10:04 am, Nicola Musatti wrote:
>>
>>> I'm not convinced this is the only reason, because it would have
>>> been just as reasonable to stipulate that catch'es go with the
>>> closest try, as it happens with else's and if's. If this were the
>>> case, the example above would result in a "try without catch" error.
>>
>> The difference is that try can have mutliple catch parts. An if
>> statement can have only one else part.
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting
> with ] [ your news-reader.  If that fails, use
> mailto:std-c++@ncar.ucar.edu    ] [              --- Please see the
> FAQ before posting. ---               ] [ FAQ:
> http://www.jamesd.demon.co.uk/csc/faq.html                       ]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In message <20d0a2b2.0403041413.13e57e69@posting.google.com>, Gregg
<gregglastname@hotmail.com> writes
>What was the rationale behind requiring the bodies of try and catch to
>be blocks instead of statements (possibly compound)? It seems
>inconsistent with other similar constructs such as if / else.
  <snip>

The  if then if then else  gotcha is so old it's almost a computing
tradition. Perhaps no one saw the need for another one.

  John
--
John Harris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gregg wrote:
> I hadn't considered the case of nested handlers with multipe catch
> clauses, and it seems obvious now that that was the reason for
> requiring the braces. However, it still strikes me as an ugly
> linguistic inconsistency.  It seems that it would have been better to
> apply rules similar to those for disambiguating nested if/else
> statements, extended to handle mulitple catch clauses.

It seems to me that it would have been better to force the if/else to
have braces, instead! Obviously, that was not feasible as it would have
broken legacy code and compatibility with C. So instead of persisting in
error and provide obscure rules for disambiguating nested statements to
keep consistency with the dubious if/else syntax, they decided to do the
right thing with try/catch. Just my opinion.

Alberto

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""P.J. Plauger"" <pjp@dinkumware.com> wrote in message
news:InG2c.81005$C65.3427@nwrddc01.gnilink.net...

> Agreed, but there are other simple rules in C/C++ that don't always give
> the "useful" result, such as x+++++y. Yet we've kept them for simplicity,
> in some dimension.

Indeed.  The thing about this particular rule, though, is that I'm having
trouble constructing a scenario in which the rule would do the right thing.
Can you find one?

> This quibble doesn't alter the fact that it was probably wise to require
> compound statements after try and catch.

Agreed.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Andrew Koenig wrote:
> ""P.J. Plauger"" <pjp@dinkumware.com> wrote in message
> news:InG2c.81005$C65.3427@nwrddc01.gnilink.net...
>=20
>=20
>>Agreed, but there are other simple rules in C/C++ that don't always giv=
e
>>the "useful" result, such as x+++++y. Yet we've kept them for simplicit=
y,
>>in some dimension.
>=20
>=20
> Indeed.  The thing about this particular rule, though, is that I'm havi=
ng
> trouble constructing a scenario in which the rule would do the right th=
ing.
> Can you find one?

It does the right thing in the simple case of a single try/catch. Easier=20
syntax in unambiguous situations, fails otherwise (requiring compound=20
statements to disambiguate). Sounds safe and useful to me, although I=20
won't actually ask for a language change.

Regards, Daniel

--=20
Daniel Frey

aixigo AG - financial solutions & technology
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Andrew Koenig"" <ark@acm.org> wrote in message
news:pnR2c.85416$aH3.2616785@bgtnsc04-news.ops.worldnet.att.net...

> ""P.J. Plauger"" <pjp@dinkumware.com> wrote in message
> news:InG2c.81005$C65.3427@nwrddc01.gnilink.net...
>
> > Agreed, but there are other simple rules in C/C++ that don't always give
> > the "useful" result, such as x+++++y. Yet we've kept them for
simplicity,
> > in some dimension.
>
> Indeed.  The thing about this particular rule, though, is that I'm having
> trouble constructing a scenario in which the rule would do the right
thing.
> Can you find one?

    x+++y    // for some definition of 'right'

And IIRC, C++ permits (x++)++, so my original example might also
parse 'correctly' and usably, in some programmer's universe. Truth
to tell, I'd give

    (x++)++ + y

slightly higher marks for readability.

> > This quibble doesn't alter the fact that it was probably wise to require
> > compound statements after try and catch.
>
> Agreed.

End of meta-quibbling.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Joe Greer" <jgreer@nsisoftware.com> wrote in message
news:78d8249b.0403050655.5b0a7d0@posting.google.com...
> rl.news@tempest-sw.com (Ray Lischner) wrote in message
news:<1785.4047f27d.858ca@prospero.island.local>...
> > On Thursday 04 March 2004 05:51 pm, Gregg wrote:
> >
> > > What was the rationale behind requiring the bodies of try and catch to
> > > be blocks instead of statements (possibly compound)?
> >
> > You need the braces to tell which catch goes with which try.
> > For example:
>
> I personally don't find this a compelling argument.  You run into a
> similar situation with if statements:
>
> if (this)
>   if (that)
> else
>  ....
>
> and one just knows that if you are going to nest, then you must use
> braces.  The same rules could apply here.  I am not really advocating
> a change, but there really should be a better rationale than that.

There would still be no way to code a nested try/catch without
using braces at least in the outer try block, ever.

The crucial difference to if/else is that one "if" is always followed by
at most one "else", whereas one "try" can have an arbitrary number
of "catch" blocks.

Cheers!

 - Risto -

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Edward Diener"" <eddielee@tropicsoft.com> wrote in message
news:wHs2c.22337$yZ1.18163@newsread2.news.pas.earthlink.net...
> Tony Burrows wrote:
> > Slightly differently
> > Why no finally which gets executed whether try or catch happens.  Ie,
> > code that always runs before a function ends?
> >
> > As a Java programmer I find it useful at times.
>
> Java needs it because it has no deterministic destruction of objects. Java
> programmers have to make sure they manually release resources whereas C++
> programmers don't have to worry about this at all. That is why a 'finally'
> has much less importance in C++ than it does in Java ( or C# ). So C++
never
> adopted such a measure, and I don't believe it needs it. A number of C++
> compiler implementations have added it as an extension to C++.

Java "finally" is executed after all branches, including the
one where the try block exits cleanly with no exception,
and where the "try" block or a "catch" block executes a
"return" statement [which itself is a little known fact even
among Java programmers themselves].  This can be very
useful sometimes, but there is no way to emulate the same
behaviour in C++ without duplicating the same code in
every point of return (including both implicit and explicit).

 - Risto -

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Risto Lankinen wrote:
 > there is no way to emulate the same
> behaviour in C++ without duplicating the same code in
> every point of return (including both implicit and explicit).

Well of course there is. You put the code in the destructor of an
object and create an automatic object of that type in the try block.
If it needs access to local variables, you do have to pass them in
to the constructor of the object.

extern bool foo(), goo();
extern void zoo(), cleanup();
void f()
{
     try {
         struct clean { ~clean() { cleanup(); } } cleaner;
         if (foo()) throw 1;
         if (goo()) return;
     }
     zoo();
}

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""P.J. Plauger"" <pjp@dinkumware.com> a    crit :
> ""Andrew Koenig"" <ark@acm.org> wrote in message
> news:pnR2c.85416$aH3.2616785@bgtnsc04-news.ops.worldnet.att.net...
>
> > ""P.J. Plauger"" <pjp@dinkumware.com> wrote in message
> > news:InG2c.81005$C65.3427@nwrddc01.gnilink.net...
> >
> > > Agreed, but there are other simple rules in C/C++ that don't always
give
> > > the "useful" result, such as x+++++y. Yet we've kept them for
> simplicity,
> > > in some dimension.
> >
> > Indeed.  The thing about this particular rule, though, is that I'm
having
> > trouble constructing a scenario in which the rule would do the right
> thing.
> > Can you find one?
>
>     x+++y    // for some definition of 'right'
>
> And IIRC, C++ permits (x++)++, so my original example might also
> parse 'correctly' and usably, in some programmer's universe. Truth
> to tell, I'd give
>

Hello,

I tried x+++++y, wich is interpreted like this

>     (x++)++ + y

but my compiler complains about the second post-increment.
Since x++ returns a temporary object, wich is not an l-value,
it says it cannot appy the second post-increment operator.
Is that correct ?

--

- Manuel
to reply, swap the name with the domain.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Manuel"" <swissonline@mzaccaria.ch> wrote in message
news:c2iob8$h9u$1@newshispeed.ch...

> > And IIRC, C++ permits (x++)++, so my original example might also
> > parse 'correctly' and usably, in some programmer's universe. Truth
> > to tell, I'd give
> >
>
> Hello,
>
> I tried x+++++y, wich is interpreted like this
>
> >     (x++)++ + y
>
> but my compiler complains about the second post-increment.
> Since x++ returns a temporary object, wich is not an l-value,
> it says it cannot appy the second post-increment operator.
> Is that correct ?

Yes. I didn't RC. I confused x++ with ++x. In C, both are rvalues;
in C++ the latter (only) is an lvalue.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ark@acm.org ("Andrew Koenig") wrote in message news:<I%d2c.156013$hR.2898353@bgtnsc05-news.ops.worldnet.att.net>...
> "Nicola Musatti" <Nicola.Musatti@ObjectWay.it> wrote in message
> news:a327cf48.0403050513.458c6946@posting.google.com...
> > rl.news@tempest-sw.com (Ray Lischner) wrote in message
> news:<1785.4047f27d.858ca@prospero.island.local>...
>
> > > You need the braces to tell which catch goes with which try.
[...]
> > I'm not convinced this is the only reason, because it would have been
> > just as reasonable to stipulate that catch'es go with the closest try,
> > as it happens with else's and if's. If this were the case, the example
> > above would result in a "try without catch" error.
>
> Not really, because each try must have at least one catch.  So although the
> "each catch goes with the closest try" rule is simple, it would fail for
> cases such as
>
>     try ... try ... catch ... catch
>
> where there is only one possible interpretation.
>
> It's easier to require programmers to be explicit.

Oh, I'm content with the current situation, but I don't consider it so
clearly cut. In my (limited) experience I seldom nest try statements,
so the alternative rule I mentioned would have been acceptable to me.

However I agree that it's simpler to state that "all try blocks
require braces" rather than "all try blocks except the innermost
require braces".

Cheers,
Nicola Musatti

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

===================================== MODERATOR'S COMMENT:
 Please don't overquote.


===================================== END OF MODERATOR'S COMMENT
Gregg wrote:

> What was the rationale behind requiring the bodies of try and catch to
> be blocks instead of statements (possibly compound)? It seems
> inconsistent with other similar constructs such as if / else. Why not
> allow
>
>    try
>       <stmt1>
>    catch (std::exception&)
>       <stmt2>
>
> where <stmt2> and <stmt2> could be either simple or compound (with
> braces) exactly as if / else?
>
> Thanks
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>

I have been reading this thread for a while and have noticed that no-one
really says nothing against the catch part.

Would it be too much to ask that you didn't have to explicitly use a
scope with a catch statement, this woudln't cause too much ambiquity,
would it?

This is somewhat comparable to the else if syntax (if we think of else
if as a single statement):

try
{
   try
   {


   }
   catch(foo)
     <statement>;
   catch(bar)
     <statement>;
}
catch(...);

--
Jukka Helle (Squider) <squidysoft dot squider at dnainternet dot net>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]