Topic: C++0x - try{}
Author: Francis Glassborow <francis.glassborow@ntlworld.com>
Date: Thu, 17 May 2001 19:56:08 GMT Raw View
In article <GDGI8J.BK0@research.att.com>, Bjarne Stroustrup
<bs@research.att.com> writes
>Similarly, I introduced the redundant "try" because I was unable to teach
>exception handling effectively without it. Despite most people's loud dislike
>of keywords in general, people seem to insist on keywords (and in particular
>on keywords that prefix constructs) for concepts that they consider new.
>(Please remember "teachability" in these discussions).
Yes, I understand that but it would be nice if the redundant 'try' were
made optional. Actually, I do not really care other than as
demonstration of a keyword that never helped a compiler but only helps
human beings:)
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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.research.att.com/~austern/csc/faq.html ]
Author: "%UN%" <%un%@liverpool.ac.uk>
Date: Thu, 17 May 2001 19:57:43 GMT Raw View
Christopher Eltschka wrote:
> Radoslav Getov wrote:
> >
> > "Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
> > news:hH9tdQAx8kA7EwR9@ntlworld.com...
> > :
> > : Well it all depends on what you understand by syntactic sugar. Keywords
> > : like 'try' are the most refined examples, they do absolutely nothing
> > : other than make humans feel comfortable, the compiler could completely
> > : ignore them and just note blocks that are followed by one or more
> > : catches.
> >
> > This reminds to me: why is it "try <block>" rather than "try <statement>"?
> > Any particular reason for it?
> >
> > The same for 'catch'.
>
> try foo();
> try bar();
> catch(E1) try baz();
> catch(E2) xy();
> catch(E3) xy2();
> catch(E4) xy3();
> catch(...) {}
>
> Now: Which catches belong to which try?
That's ridiculous. The first try doesn't have any catches, quite clearly.
Now:
try
try foo();
catch (E1) bar();
catch (E2) bar2();
is firstly redundant, and secondly clearly wrong, as the catch(E2) must bind
with the previous catch, and hence with the second try; and so the first try can
have no catches.
And
try
try foo();
catch (E1) bar();
foo2();
catch (E2) bar2();
clearly has the same redundancy of tries, and a hanging catch (E2) which doesn't
match a try, if the try foo() is the statement which goes with the original
try. Otherwise we may allow the foo2() to bind with the original try, and all
is well.
Of course,
try foo(),
try foo2();
catch(E1) bar();
catch(E2) bar2();
foo3();
catch(E3) bar3();
would have the obvious consequences.
James S. Adelman
---
[ 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.research.att.com/~austern/csc/faq.html ]
Author: James Dennett <jdennett@acm.org>
Date: Thu, 17 May 2001 20:42:30 GMT Raw View
Francis Glassborow wrote:
>
> In article <GDGI8J.BK0@research.att.com>, Bjarne Stroustrup
> <bs@research.att.com> writes
> >Similarly, I introduced the redundant "try" because I was unable to teach
> >exception handling effectively without it. Despite most people's loud dislike
> >of keywords in general, people seem to insist on keywords (and in particular
> >on keywords that prefix constructs) for concepts that they consider new.
> >(Please remember "teachability" in these discussions).
>
> Yes, I understand that but it would be nice if the redundant 'try' were
> made optional.
I think that C++ suffers from having insufficient redundancy in
its notation -- this is part of what makes it hard for compiler
writers to give good diagnostics for syntax errors.
> Actually, I do not really care other than as
> demonstration of a keyword that never helped a compiler but only helps
> human beings:)
As I've noted above -- in incorrect code, otherwise redundant
tokens can help the compiler too. The fact that it helps
human beings to read code is more important, of course.
Use the much-maligned "auto" for your demonstration, until
you manage to get it used to eliminate some of the ambiguity
which exists because auto *is* optional! :)
-- James Dennett
---
[ 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.research.att.com/~austern/csc/faq.html ]
Author: Michael Lee Finney <michael.finney@acm.org>
Date: Thu, 17 May 2001 21:36:22 GMT Raw View
In article <3B03EB92.C1136374@liv.ac.uk>, %un%
@liverpool.ac.uk says...
> > try foo();
> > try bar();
> > catch(E1) try baz();
> > catch(E2) xy();
> > catch(E3) xy2();
> > catch(E4) xy3();
> > catch(...) {}
> >
> > Now: Which catches belong to which try?
>
> That's ridiculous. The first try doesn't have any catches, quite clearly.
I didn't write it, but let me show a few (not the
only) parses using indentation instead of braces.
Clearly "catch(E3)" and "catch(E4)" can be assigned to
multiple locations. Nor is a rule like "associate with
the closest try" really appropriate.
On the other hand, I'm not at all sure that catch
couldn't be followed by <statement> instead of
<block>.
-------------------------------
try
foo();
try
bar();
catch(E1)
try
baz();
catch(E2)
xy();
catch(E3)
xy2();
catch(E4)
xy3();
catch(...)
{}
------------------------------
try
foo();
try
bar();
catch(E1)
try
baz();
catch(E2)
xy();
catch(E3)
xy2();
catch(E4)
xy3();
catch(...)
{}
-------------------------------
try
foo();
try
bar();
catch(E1)
try
baz();
catch(E2)
xy();
catch(E3)
xy2();
catch(E4)
xy3();
catch(...)
{}
-------------------------------
---
[ 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.research.att.com/~austern/csc/faq.html ]
Author: "Radoslav Getov" <nospam@mai.com>
Date: Wed, 16 May 2001 18:28:26 GMT Raw View
"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:hH9tdQAx8kA7EwR9@ntlworld.com...
:
: Well it all depends on what you understand by syntactic sugar. Keywords
: like 'try' are the most refined examples, they do absolutely nothing
: other than make humans feel comfortable, the compiler could completely
: ignore them and just note blocks that are followed by one or more
: catches.
This reminds to me: why is it "try <block>" rather than "try <statement>"?
Any particular reason for it?
The same for 'catch'.
Any chance for a change?
Radoslav Getov
---
[ 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.research.att.com/~austern/csc/faq.html ]
Author: Christopher Eltschka <celtschk@dollywood.itp.tuwien.ac.at>
Date: Wed, 16 May 2001 20:16:09 GMT Raw View
Radoslav Getov wrote:
>
> "Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
> news:hH9tdQAx8kA7EwR9@ntlworld.com...
> :
> : Well it all depends on what you understand by syntactic sugar. Keywords
> : like 'try' are the most refined examples, they do absolutely nothing
> : other than make humans feel comfortable, the compiler could completely
> : ignore them and just note blocks that are followed by one or more
> : catches.
>
> This reminds to me: why is it "try <block>" rather than "try <statement>"?
> Any particular reason for it?
>
> The same for 'catch'.
try foo();
try bar();
catch(E1) try baz();
catch(E2) xy();
catch(E3) xy2();
catch(E4) xy3();
catch(...) {}
Now: Which catches belong to which try?
---
[ 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.research.att.com/~austern/csc/faq.html ]