[system] - system_error
Hi, shouldn't system_error::const char * what() const contain throw ()? regards, Oliver
<Oliver.Kowalke@qimonda.com> wrote in message news:5D4F031442F5CB489CF88277DDBACCDD054D060B@drsse401.eu.infineon.com...
Hi, shouldn't system_error::const char * what() const contain throw ()?
Good question. I don't know the answer. The standard (for std::exception, which is the eventual base class) says: virtual const char* what() const throw(); system_error::what catches exceptions, so it never throws. I afraid I still don't know the rule as to when you need to provide a throw() specifier rather than just documenting that a function never throws. Is there guidance from exception experts? --Beman
Greetings, everyone. This is my first time posting here, so if I screw this up, please bear with me. On 6/29/06, Beman Dawes <bdawes@acm.org> wrote:
I afraid I still don't know the rule as to when you need to provide a throw() specifier rather than just documenting that a function never throws.
Is there guidance from exception experts?
I have spoken with Bjarne Stroustrup about this (access to "the man" is one of the benefits of living near Texas A&M University), and he is of the opinion that exception specifications are never reliable and should not be used, as they give programmers a false sense of security. Thus, exception guarantees should be documented in comments (or in some other variety of documentation), rather than through throw() specifications. Jeremy
On Thu, 29 Jun 2006 11:37:11 -0500, "Jeremy Day" <jeremy.day@gmail.com> wrote:
Greetings, everyone. This is my first time posting here, so if I screw this up, please bear with me.
On 6/29/06, Beman Dawes <bdawes@acm.org> wrote:
I afraid I still don't know the rule as to when you need to provide a throw() specifier rather than just documenting that a function never throws.
Is there guidance from exception experts?
I have spoken with Bjarne Stroustrup about this [...] Thus, exception guarantees should be documented in comments (or in some other variety of documentation), rather than through throw() specifications.
But Beman was specifically talking about throw() [read: no-throw], not exception specifications in general. Our docs say: <http://www.boost.org/more/lib_guide.htm#Exception-specification> FWIW, my style is to use the throw() on exception classes; basically because it reminds me to double check the implementation for unwanted sources of exceptions --std::string being a common one. PS: out of curiosity, Jeremy, didn't you ask why the don't get removed from the standard then? --Gennaro.
On 6/29/06, Gennaro Prota <gennaro_prota@yahoo.com> wrote:
But Beman was specifically talking about throw() [read: no-throw], not exception specifications in general. Our docs say:
Right. I'm just suggesting that a programmer might do something catastrophic, such as: void foo() const throw() { throw std::bad_exception; } This obviously violates the no-throw specification but is, as near as I can tell, entirely legal. A more likely case would be that foo calls some other function, and that function throws an exception that isn't in foo's exception specification (which, in this case, is a no-throw specification). However, I could be wrong. I certainly have been before. PS: out of curiosity, Jeremy, didn't you ask why the don't get removed
from the standard then?
I did in fact ask that very question. He said that exception specifications seemed like a good idea at the time, but have over time proved to be not quite as good as expected. They cannot be removed now, because people do use them, and you need to maintain backwards compatibility. Jeremy
"Beman Dawes" <bdawes@acm.org> skrev i meddelandet news:e80sim$5ng$1@sea.gmane.org...
<Oliver.Kowalke@qimonda.com> wrote in message news:5D4F031442F5CB489CF88277DDBACCDD054D060B@drsse401.eu.infineon.com...
Hi, shouldn't system_error::const char * what() const contain throw ()?
Good question. I don't know the answer. The standard (for std::exception, which is the eventual base class) says:
virtual const char* what() const throw();
system_error::what catches exceptions, so it never throws.
I afraid I still don't know the rule as to when you need to provide a throw() specifier rather than just documenting that a function never throws.
Is there guidance from exception experts?
I'm not one of those, but have notice that several compilers (MSVC7.1, Comeau) complain about virtual functions having a less strict throw spec than the base class functions they override. Seems to me like there would be a *real* surprise if catch (const std::exception& e) { e->what(); } actually threw another exception, even if e is a derived exception class. Bo Persson
Beman Dawes wrote:
<Oliver.Kowalke@qimonda.com> wrote in message news:5D4F031442F5CB489CF88277DDBACCDD054D060B@drsse401.eu.infineon.com...
Hi, shouldn't system_error::const char * what() const contain throw ()?
Good question. I don't know the answer. The standard (for std::exception, which is the eventual base class) says:
virtual const char* what() const throw();
system_error::what catches exceptions, so it never throws.
I afraid I still don't know the rule as to when you need to provide a throw() specifier rather than just documenting that a function never throws.
You can't relax an exception specification in an overrider, only tighten it, so yes, system_error::what() needs throw(). I believe that a conforming compiler will reject it without the throw() specification.
On Thu, 29 Jun 2006 22:54:23 +0300, "Peter Dimov" <pdimov@mmltd.net> wrote:
You can't relax an exception specification in an overrider, only tighten it, so yes, system_error::what() needs throw(). I believe that a conforming compiler will reject it without the throw() specification.
Your belief is right :-) The program is ill-formed per 15.4/3. To me this is a good argument for using no-throw specifications on virtual functions, if they don't throw. It's perhaps worth noting that compiler-declared special member functions (e.g. destructor) have an implicit exception specification which as strict as the directly called functions allow for (not more, not less). Thus, for instance, the following is ok: struct my_ex : public std::exception { //~my_ex() {} }; but it becomes ill-formed if you uncomment the destructor definition. If a special member is virtual then the compiler-generated declaration may render the program ill-formed exactly because, for the rule above, it may relax the exception specification. --Gennaro.
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:009901c69bb5$d7754310$6407a8c0@pdimov2...
Beman Dawes wrote:
<Oliver.Kowalke@qimonda.com> wrote in message news:5D4F031442F5CB489CF88277DDBACCDD054D060B@drsse401.eu.infineon.com...
Hi, shouldn't system_error::const char * what() const contain throw ()?
Good question. I don't know the answer. The standard (for std::exception, which is the eventual base class) says:
virtual const char* what() const throw();
system_error::what catches exceptions, so it never throws.
I afraid I still don't know the rule as to when you need to provide a throw() specifier rather than just documenting that a function never throws.
You can't relax an exception specification in an overrider, only tighten it, so yes, system_error::what() needs throw(). I believe that a conforming compiler will reject it without the throw() specification.
Fixed. Thanks! --Beman
participants (6)
-
Beman Dawes -
Bo Persson -
Gennaro Prota -
Jeremy Day -
Oliver.Kowalke＠qimonda.com -
Peter Dimov