Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 918929
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: May 15, 20262026-05-15T18:27:30+00:00 2026-05-15T18:27:30+00:00

The C++ Standard states the following about virtual functions that have exception specifications: If

  • 0

The C++ Standard states the following about virtual functions that have exception specifications:

If a virtual function has an exception-specification, all declarations, including the definition, of any function that overrides that virtual function in any derived class shall only allow exceptions that are allowed by the exception-specification of the base class virtual function (C++03 §15.4/3).

Thus, the following is ill-formed:

struct B {
    virtual void f() throw() { } // allows no exceptions
};
struct D : B {
    virtual void f() { }         // allows all exceptions
};

(1) Does this rule apply to destructors? That is, is the following well-formed?

struct B {
    virtual ~B() throw() { }
};
struct D : B {
    virtual ~D() { }
};

(2) How does this rule apply to an implicitly declared destructor? That is, is the following well-formed?

struct B {
    virtual ~B() throw() { }
};
struct D : B { 
    // ~D() implicitly declared
};

While in the general case one should never write an exception specification, this question has practical implications because the std::exception destructor is virtual and has an empty exception specification.

Since it is good practice not to allow an exception to be thrown from a destructor, let’s assume for the sake of simplifying any examples that a destructor either allows all exceptions (that is, it has no exception specification) or it allows no exceptions (that is, it has an empty exception specification).

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-05-15T18:27:31+00:00Added an answer on May 15, 2026 at 6:27 pm

    (1) Does this rule apply to destructors?

    Yes, this rule applies to destructors (there is no exception to the rule for destructors), so this example is ill-formed. In order to make it well-formed, the exception specification of ~D() must be compatible with that of ~B(), e.g.,

    struct B {
        virtual ~B() throw() { }
    };
    struct D : B {
        virtual ~D() throw() { }
    };
    

    (2) How does this rule apply to implicitly declared special member function?

    The C++ Standard says the following about implicitly declared special member functions:

    An implicitly declared special member function shall have an exception-specification.

    If f is an implicitly declared default constructor, copy constructor, destructor, or copy assignment operator, its implicit exception-specification specifies the type-id T if and only if T is allowed by the exception-specification of a function directly invoked by f’s implicit
    definition;

    f shall allow all exceptions if any function it directly invokes allows all exceptions, and f shall allow no exceptions if every function it directly invokes allows no exceptions (C++03 §15.4/13).

    What functions are directly invoked by an implicitly declared destructor?

    After executing the body of the destructor and destroying any automatic objects allocated within the body, a destructor for class X calls

    • the destructors for X’s direct members,
    • the destructors for X’s direct base classes and,
    • if X is the type of the most derived class, its destructor calls the destructors for X’s virtual base classes

    (C++03 §12.4/6; reformatted for easier reading).

    So, an implicitly declared destructor has an exception specification that allows any exceptions allowed by any of those destructors. To consider the example from the question:

    struct B {
        virtual ~B() throw() { }
    };
    struct D : B { 
        // ~D() implicitly declared
    };
    

    The only destructor called by the implicitly declared ~D() is ~B(). Since ~B() allows no exceptions, ~D() allows no exceptions and it is as if it were declared virtual ~D() throw().

    This exception specification is obviously compatible with ~B()‘s, so this example is well-formed.


    As a practical example of why this matters, consider the following:

    struct my_exception : std::exception {
        std::string message_;
    };
    

    ~string() allows all exceptions, so the implicitly declared ~my_exception() allows all exceptions. The base class destructor, ~exception(), is virtual and allows no exceptions, so the derived class destructor is incompatible with the base class destructor and this is ill-formed.

    To make this example well-formed, we can explicitly declare the destructor with an empty exception specification:

    struct my_exception : std::exception {
        virtual ~my_exception() throw() { }
        std::string message_;
    };
    

    While the rule of thumb is never to write an exception specification, there is at least this one common case where doing so is necessary.

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

The standard explicitly states that main has two valid (i.e., guaranteed to work) signatures;
The C++0x standard working draft states (section 6.5.4) the following about the begin() and
I have I standard Emacs/nxhtml install. My nxhtml-autoload.el has the following line (I use
The C++ standard (ISO/IEC 14882:03) states the following ( 2.11 / 2 ): Furthermore,
I have some question about behavior of std::async function with std::launch::async policy & std::future
The C99 standard document has the following example in the section related to the
I have the following Javascript where I modified the standard Google Maps API initialize()
The C++ Language Standard states the following concerning template components in the Standard Library:
I have some code that I've managed to narrow down to the following smallest-code
The C++11 standard states that, if the conditions for copy elision are met (

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.