sc_unwind_exception constructor/destructor

From: Philipp A. Hartmann <philipp.hartmann@offis.de>
Date: Mon Jan 17 2011 - 08:06:01 PST

John, all,

sorry for being late in catching this issue. There is a minor oversight
with the current declaration of sc_unwind_exception and sc_report:
Their destructors miss the required throw() specifier:

   virtual ~sc_unwind_exception() /* requires: throw() */;
   virtual ~sc_report() /* requires: throw() */;

sc_unwind_exception/sc_report are derived from std::exception, which has

      virtual ~exception() throw();

Some compilers (most notably GCC since some 3.x version) don't like
the missing throw specifier and are correct from a C++ POV:

      error: looser throw specifier for
             ‘virtual sc_unwind_exception::~sc_unwind_exception()’

See ISO/IEC 14882:2003(E), 15.4(3):

 "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."

That said, what's the motivation to make the copy ctor and destructor
protected in sc_unwind_exception?
  - Yes, this effectively prohibits catching these objects by-value.
  - Yes, this can be considered good practice.
  - No, it's not the same for sc_report.
  - No, it does NOT help in the requirement to re-throw them.

    Both, "catch( sc_unwind_exception const & )" or even "catch(...)"
could still swallow the exception completely, if not re-thrown by
the application. I don't feel strongly about this, apart from the fact
that this is not consistent with sc_report without obvious reasons…

Greetings from Oldenburg,
  Philipp

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany · http://offis.de/en/
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Jan 17 08:06:28 2011

This archive was generated by hypermail 2.1.8 : Mon Jan 17 2011 - 08:06:33 PST