Troubles with exception specification

Troubles with exception specification

[Ryszard Kabatek]

There are 2 problems with the exception specification in egcs-1.1.

1. In the sample below, the virtual function D::func,
that overrides the virtual function B::func, 
has a less restrictive exception specification.
However the compiler does compile the sample without any warning!

2. The call of B::func should throw `bad_exception', but it doesn't!

On Linux (RedHat 5.1, PC) it causes:
Aborted (core dumped),

on Linux (S.u.S.E. 5.1, PC, libc 5)
IOT trap/Abort.


//////////
// main.cc
//////////

# include <iostream.h>
# include <stdexcept>

class B {
  public:
    virtual ~B() throw() {}
    virtual void func() throw(logic_error, bad_exception)
    {throw runtime_error("XXL");}
};

class D : public B {
  public:
    virtual void func() {}
};

int main()
{
  try {
     B b;
     b.func();
  }
  catch (exception& exc) {
     cerr << exc.what() << '\n';
  }
}


Ryszard Kabatek
---
Martin-Luther University Halle-Wittenberg
Department of Physical Chemistry
Geusaer Str. 88, 06217 Merseburg, Germany
Tel. +49 3461 46 2487 Fax. +49 3461 46 2129

Re: Troubles with exception specification

[Martin von Loewis]

>> 2. The call of B::func should throw `bad_exception', but it doesn't!

Thanks for your bug report. After closer inspection, and several
discussions, this is what I found:

In section 14.6.3 of "The C++ programming language", Stroustrup
explains that adding bad_exception to the exception specification will
activate the "exception mapping", which means that exceptions not
listed in the specification will be mapped to bad_exception by the
implementation.

In section 15.5.2 of the C++ Standard, paragraph 2 explains that such
mapping is performed only if unexpected throws or rethrows, which it
doesn't do by default (18.6.6.2).

Mr Stroustrup confirms that this is a contradiction between his book
and the adopted standard. He maintains that the standard should have
specified such exception mapping, and has brought this issue before
the standards committee
( http://www.research.att.com/~bs/3rd_issues.html ).

egcs currently implements the standards behaviour and not Stroustrup's
description. I'd propose that this is remains unchanged until a
decision is made by ISO.

Please note that you can work-around this discrepancy. Just define an
unexpected_handler:

#include <exception>

void my_unexpected()
{
  throw std::bad_exception();
}

int main()
{
  std::set_unexpected(my_unexpected);
  //more code
}

Hope this helps,
Martin

P.S. Even though this came up the first time, I propose to add it to
the FAQ ("Why does bad_exception not work?") or as a non-bug to the
"Known bugs list".

FAQ vs Known Bugs List vs .texi Docs

[Gerald Pfeifer]

On Thu, 5 Nov 1998, Martin von Loewis wrote:
> P.S. Even though this came up the first time, I propose to add it to
> the FAQ ("Why does bad_exception not work?") or as a non-bug to the
> "Known bugs list".

I believe we should not add too much the FAQ (especially non-FAQs), but
I'd be willing to accept that for the "Known bugs list", if you submit
a patch.


In general, though, what about the .texi documentation? There is a special
section about bugs and non-bugs. Shouldn't stuff like that go there as
well? Or only there?

We could put the .texi documentation on the web and link that part.

Just an idea...
Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/