Topic: throw(...)
Author: philippe_mori@hotmail.com ("Philippe Mori")
Date: Thu, 2 Jan 2003 19:22:38 +0000 (UTC) Raw View
>
> In my proposal, exception specifications would be the same as currently,
but with an explicit syntax for
> might-throw-anything.
> So code without exception specification may do what it currently does:
throw anything. Same as my proposed
> throw(...). With the difference the latter *IS* an exception
specification, whereas the former *MIGHT* be
> (in practice, probably not. But this "probably" might change over time.).
> This *might* is the ambiguity I mentioned (and I'd like to see fixed).
>
>
> regards,
> Thomas
>
In fact, this may be usefull if someone want to always uses exception
specifications... An option on the compiler could be added to force
exception specification (to ensure that exception are specified if we want
it). Even with that option, it would not cause any compatibility problem
provide there is a way to disable that extra option for specific files or
section of code (pragma).
---
[ 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 ]
Author: a9804814@unet.univie.ac.at (Thomas Mang)
Date: Tue, 31 Dec 2002 19:23:04 +0000 (UTC) Raw View
Okay, this reply is a bit late; it seemed my original message was lost
somewhere in www.......
> a9804814@unet.univie.ac.at (Thomas Mang) wrote in message
news:<3E05DA7B.9D13674D@unet.univie.ac.at>...
> > Hello,
>
> Hi!
>
> >
> > Why isn't there a declaration like throw(...) to explicitly indicate
an
> > exception specification, but that any exception might be thrown?
> >
>
> The language must be backwards-compatible. Code without exception
> specifications can still throw, and it can throw anything. We can't
> change that. Thus, no exception specification = throws anything. An
> empty exception specification = throws nothing. Where's the
> ambiguity? As far as I can tell, adding "throw(...)" only adds
> ambiguity.
I don't see where backward compatibility would be affected.
In my proposal, exception specifications would be the same as currently,
but with an explicit syntax for
might-throw-anything.
So code without exception specification may do what it currently does:
throw anything. Same as my proposed
throw(...). With the difference the latter *IS* an exception
specification, whereas the former *MIGHT* be
(in practice, probably not. But this "probably" might change over
time.).
This *might* is the ambiguity I mentioned (and I'd like to see fixed).
regards,
Thomas
---
[ 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 ]
Author: a9804814@unet.univie.ac.at (Thomas Mang)
Date: Sun, 29 Dec 2002 04:05:02 +0000 (UTC) Raw View
Allan W schrieb:
> a9804814@unet.univie.ac.at (Thomas Mang) wrote
> > Hello,
> >
> >
> > The current implementation of an exception-specification that may throw
> > any exception is not to declare any exception specification:
> >
> > int foo();
> >
> > Sort of ambiguity (for readers of the program, not the compiler)
> >
> > Why isn't there a declaration like throw(...) to explicitly indicate an
> > exception specification, but that any exception might be thrown?
>
> There are several different notations.
>
> int foo(); //throw(...)
>
> or
>
> /** Function: foo()
> *
> * Purpose: Calculate the foo-factor of current customer
> *
> * Arguments: None (uses current state of singleton object Bar)
> *
> * Requirements: Baz must have a current customer
> *
> * Returns: Foo-factor of current customer (0 to 100)
> * See "Foofactor.doc" for a detailed discussion of
> * the algorithm, plus an explanation of what a foo
> * factor is and why it's relevant to Baz processing.
> *
> * Throws: No exceptions generated directly
> * Propogates any exceptions thrown by Bar function members
> *
> * Modification History:
> * 17 Nov 02 Allan_W Original Version
> * 24 Dec 02 Thomas Mang Fix bug with very last customer
> **/
> int foo();
>
> or
>
> #define maythrow
> int foo() maythrow;
>
> I'm sure you can think of still other notations.
Sure I can, but I'd prefer getting the syntax dictated by the standard over
stressing my brain :-)
A standardized way would be really nice to solve the
"did-he-mean-might-throw-anything or
did-he-mean-I-don't-care-about-exception-specifications" - puzzle.
And who knows, maybe compilers may want to know this sooner or later too to
perform optimizations or other stuff.
It could be that simple.........if we had throw(...).................. :-)
cheers,
Thomas
---
[ 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 ]
Author: a9804814@unet.univie.ac.at (Thomas Mang)
Date: Thu, 2 Jan 2003 04:14:57 +0000 (UTC) Raw View
Joshua Lehrer schrieb:
> a9804814@unet.univie.ac.at (Thomas Mang) wrote in message news:<3E05DA7B.9D13674D@unet.univie.ac.at>...
> > Hello,
>
> Hi!
>
> >
> > Why isn't there a declaration like throw(...) to explicitly indicate an
> > exception specification, but that any exception might be thrown?
> >
>
> The language must be backwards-compatible. Code without exception
> specifications can still throw, and it can throw anything. We can't
> change that. Thus, no exception specification = throws anything. An
> empty exception specification = throws nothing. Where's the
> ambiguity? As far as I can tell, adding "throw(...)" only adds
> ambiguity.
I don't see where backward compatibility would be affected.
In my proposal, exception specifications would be the same as currently, but with an explicit syntax for
might-throw-anything.
So code without exception specification may do what it currently does: throw anything. Same as my proposed
throw(...). With the difference the latter *IS* an exception specification, whereas the former *MIGHT* be
(in practice, probably not. But this "probably" might change over time.).
This *might* is the ambiguity I mentioned (and I'd like to see fixed).
regards,
Thomas
---
[ 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 ]
Author: usenet_cpp@lehrerfamily.com (Joshua Lehrer)
Date: Thu, 26 Dec 2002 16:40:38 +0000 (UTC) Raw View
a9804814@unet.univie.ac.at (Thomas Mang) wrote in message news:<3E05DA7B.9D13674D@unet.univie.ac.at>...
> Hello,
Hi!
>
> Why isn't there a declaration like throw(...) to explicitly indicate an
> exception specification, but that any exception might be thrown?
>
The language must be backwards-compatible. Code without exception
specifications can still throw, and it can throw anything. We can't
change that. Thus, no exception specification = throws anything. An
empty exception specification = throws nothing. Where's the
ambiguity? As far as I can tell, adding "throw(...)" only adds
ambiguity.
joshua lehrer
factset research systems
---
[ 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 ]
Author: allan_w@my-dejanews.com (Allan W)
Date: Thu, 26 Dec 2002 19:29:30 +0000 (UTC) Raw View
a9804814@unet.univie.ac.at (Thomas Mang) wrote
> Hello,
>
>
> The current implementation of an exception-specification that may throw
> any exception is not to declare any exception specification:
>
> int foo();
>
> Sort of ambiguity (for readers of the program, not the compiler)
>
> Why isn't there a declaration like throw(...) to explicitly indicate an
> exception specification, but that any exception might be thrown?
There are several different notations.
int foo(); //throw(...)
or
/** Function: foo()
*
* Purpose: Calculate the foo-factor of current customer
*
* Arguments: None (uses current state of singleton object Bar)
*
* Requirements: Baz must have a current customer
*
* Returns: Foo-factor of current customer (0 to 100)
* See "Foofactor.doc" for a detailed discussion of
* the algorithm, plus an explanation of what a foo
* factor is and why it's relevant to Baz processing.
*
* Throws: No exceptions generated directly
* Propogates any exceptions thrown by Bar function members
*
* Modification History:
* 17 Nov 02 Allan_W Original Version
* 24 Dec 02 Thomas Mang Fix bug with very last customer
**/
int foo();
or
#define maythrow
int foo() maythrow;
I'm sure you can think of still other notations.
---
[ 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 ]
Author: a9804814@unet.univie.ac.at (Thomas Mang)
Date: Mon, 23 Dec 2002 18:27:02 +0000 (UTC) Raw View
Hello,
The current implementation of an exception-specification that may throw
any exception is not to declare any exception specification:
int foo();
However, this is exactly the same as code without any exception
specification at all (but the semantic is different: without any
exception specification, the programmer intends to be silent about
exceptions at all. With a may-throw-any exception specification, the
message is that the implementation of the function cannot guarantee that
no exception or only exceptions of specific (known) types will be
thrown.).
Sort of ambiguity (for readers of the program, not the compiler)
Why isn't there a declaration like throw(...) to explicitly indicate an
exception specification, but that any exception might be thrown?
I do not want to start here a discussion about the general usefulness of
exception specification at all. I am well aware most don't use them for
various reasons (extra code, degraded performance.....). Nevertheless,
they are part of the standard, and appear in code.
I just point out the strange "syntax" for the may-throw-anything
exception specification and how easy and intuitive it'd be to fix this.
Also, wouldn't collide with current code.
best regards,
Thomas
---
[ 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 ]