Topic: Exception specifications for <stdexcept> and <exception>


Author: Valentin Bonnard <bonnardv@pratique.fr>
Date: 1998/06/23
Raw View
Steve Clamage <stephen.clamage@sun.com> writes:

> tanveerg@erehwon.com (Tanveer Gani) writes:
>
> >I came across following possible problems in the Nov 97 Draft Standard:
>
> >Sec 15.4 [except.spec] says in paragraph 3 that an overriding virtual
> >function shall allow only exceptions that are allowed by the exception
> >specification of the overriden base-class virtual function.
>
> >However, I note that in section 18.6.1 [lib.exception], the destructor
> >for class std::exception is defined as
> >
> >  virtual ~exception() throw();
> >
> >but in section 19.1.1 [lib.logic.error], no destructors are defined
> >for the class std::logic_error. Thus, the compiler rightly complains
> >that the exception specification of the (generated) default destructor
> >does not match that of the base class destructor. In fact none of the
> >classes in <stdexcept> have destructors defined.

> Of course, an implementation is obligated to provide a working
> library,

Yes

> and so should provide declared destructors with
> exception specifications.

It doesn't need to declare them. An implicitly generated one
is ok, as long as all member classes have the correct
exception specifications on their destructors (recursivly).

For example, if the class internaly uses a string, then the
implementation must have the following declaration:

basic_string<C,A>::~basic_string () throw ()

which is a good idea anyway.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: tanveerg@erehwon.com (Tanveer Gani)
Date: 1998/06/18
Raw View


hinnant@_anti-spam_lightlink.com (Howard Hinnant) writes:
<<
The compiler generated destructors should work fine according to 15.4 para 13:
[snip]
>>

clamage@Eng (Steve Clamage) writes:
<<
So if class std::logic_error doesn't compile, it is definitely
an error in the implementation of the class or of the compiler.
>>

Thanks for the help. Guess it's time to send in a minor-bug report to our front-end vendor.

-- Tanveer Gani



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: stephen.clamage@sun.com (Steve Clamage)
Date: 1998/06/17
Raw View
tanveerg@erehwon.com (Tanveer Gani) writes:

>I came across following possible problems in the Nov 97 Draft Standard:

>Sec 15.4 [except.spec] says in paragraph 3 that an overriding virtual
>function shall allow only exceptions that are allowed by the exception
>specification of the overriden base-class virtual function.

>However, I note that in section 18.6.1 [lib.exception], the destructor
>for class std::exception is defined as
>
>  virtual ~exception() throw();
>
>but in section 19.1.1 [lib.logic.error], no destructors are defined
>for the class std::logic_error. Thus, the compiler rightly complains
>that the exception specification of the (generated) default destructor
>does not match that of the base class destructor. In fact none of the
>classes in <stdexcept> have destructors defined.

>Is this a defect in the Standard? Has this been fixed in the approved
>ANSI version? If so, how?

The FDIS does not differ in any important way from the November
1997 draft. (Page numbers, headers, and footers are different,
and some trivial typos were fixed.)

What you point out could be considered a defect. The introductory
library material says that description of (in particular)
destructors are omitted when the default version will serve,
and that it is unspecified whether an implementation provides
a declaration and definition of them.

So the wording in the introductory material could be
amended to say something about exception specficiations, or
the destructors should be added to the derived exception
classes, or the semantics of default destructors could be
amended to say that exception specifications are taken into
account. I'd say that last is unlikely to get through as
a "clarification", however.

Of course, an implementation is obligated to provide a working
library, and so should provide declared destructors with
exception specifications.

--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: hinnant@_anti-spam_lightlink.com (Howard Hinnant)
Date: 1998/06/17
Raw View
In article <6m76ch$g7b@engnews1.Eng.Sun.COM>, stephen.clamage@sun.com
(Steve Clamage) wrote:

> tanveerg@erehwon.com (Tanveer Gani) writes:
>
> >However, I note that in section 18.6.1 [lib.exception], the destructor
> >for class std::exception is defined as
> >
> >               virtual ~exception() throw();
> >
> >but in section 19.1.1 [lib.logic.error], no destructors are defined
> >for the class std::logic_error. Thus, the compiler rightly complains
> >that the exception specification of the (generated) default destructor
> >does not match that of the base class destructor. In fact none of the
> >classes in <stdexcept> have destructors defined.
>
> >Is this a defect in the Standard? Has this been fixed in the approved
> >ANSI version? If so, how?
>
> What you point out could be considered a defect. The introductory
> library material says that description of (in particular)
> destructors are omitted when the default version will serve,
> and that it is unspecified whether an implementation provides
> a declaration and definition of them.
>
> So the wording in the introductory material could be
> amended to say something about exception specficiations, or
> the destructors should be added to the derived exception
> classes, or the semantics of default destructors could be
> amended to say that exception specifications are taken into
> account. I'd say that last is unlikely to get through as
> a "clarification", however.
>
> Of course, an implementation is obligated to provide a working
> library, and so should provide declared destructors with
> exception specifications.

The compiler generated destructors should work fine according to 15.4 para 13:

<quote>
13An  implicitly  declared  special  member  function (clause _special_)
  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 func-
  tion directly invoked by f's implicitly 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.  [Example:
  struct A {
      A();
      A(const A&) throw();
      ~A() throw(X);
  };
  struct B {
      B() throw();
      B(const B&) throw();
      ~B() throw(Y);
  };
  struct D : public A, public B {
          // Implicit declaration of D::D();
          // Implicit declaration of D::D(const D&) throw();
          // Implicit declaration of D::~D() throw (X,Y);
  };
  Furthermore,  if A::~A() or B::~B() were virtual, D::~D() would not be
  as restrictive as that of A::~A, and the program would  be  ill-formed
  since  a  function that overrides a virtual function from a base class
  shall have an exception-specification at least as restrictive as  that
  in the base class.  ]
<end quote>

-Howard


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: clamage@Eng (Steve Clamage)
Date: 1998/06/17
Raw View
hinnant@_anti-spam_lightlink.com (Howard Hinnant) writes:

>In article <6m76ch$g7b@engnews1.Eng.Sun.COM>, stephen.clamage@sun.com
>(Steve Clamage) wrote:
>
>> tanveerg@erehwon.com (Tanveer Gani) writes:
>>
>> >However, I note that in section 18.6.1 [lib.exception], the destructor
>> >for class std::exception is defined as
>> >
>> >               virtual ~exception() throw();
>> >
>> >but in section 19.1.1 [lib.logic.error], no destructors are defined
>> >for the class std::logic_error. Thus, the compiler rightly complains
>> >that the exception specification of the (generated) default destructor
>> >does not match that of the base class destructor. In fact none of the
>> >classes in <stdexcept> have destructors defined.
>>
>> >Is this a defect in the Standard? Has this been fixed in the approved
>> >ANSI version? If so, how?
>>
>> What you point out could be considered a defect. ...
>>
>> So the wording in the introductory material could be ...
>> amended to say that exception specifications are taken into
>> account. ...
>>
>> Of course, an implementation is obligated to provide a working
>> library, and so should provide declared destructors with
>> exception specifications.
>
>The compiler generated destructors should work fine according to
>15.4 para 13:

Right you are. I didn't find that paragraph when I looked up
the rules for implicitly-defined member functions. So the FDIS
is OK on that point. (Modulo ease of finding all the details of
any particular item. Sigh.)

So if class std::logic_error doesn't compile, it is definitely
an error in the implementation of the class or of the compiler.

--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]