This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++17 status.

2233. bad_function_call::what() unhelpful

Section: 22.10.17.2 [func.wrap.badcall] Status: C++17 Submitter: Jonathan Wakely Opened: 2013-01-05 Last modified: 2017-09-07

Priority: 3

View all issues with C++17 status.

Discussion:

A strict reading of the standard implies std::bad_function_call{}.what() returns the same string as std::exception{}.what() which doesn't help to know what happened if you catch an exception by reference to std::exception.

For consistency with bad_weak_ptr::what() it should return "bad_function_call".

See c++std-lib-33515 for other details.

There was a considerable support on the reflector to instead change the specification of both bad_weak_ptr::what() and bad_function_call::what() to return an implementation-defined string instead.

[2013-03-15 Issues Teleconference]

Moved to Open.

Consensus that we want consistency in how this is treated. Less consensus on what the common direction should be.

Alisdair to provide wording proposing that all string literals held by standard exception objects are either unspecified, or implmentation defined.

[2014-02-15 Issauqah]

STL: I think it should be an implementation-defined NTBS, same on bad_weak_ptr. I will write a PR.

[2014-03-27, STL provides improved wording]

The new wording reflects better the general agreement of the committee, see also issue 2376(i) for similar wording.

[2014-03-28 Library reflector vote]

The issue has been identified as Tentatively Ready based on five votes in favour.

Proposed resolution:

This wording is relative to N3936.

  1. Edit [func.wrap.badcall.const]:

    bad_function_call() noexcept;

    -1- Effects: constructs a bad_function_call object.

    -?- Postconditions: what() returns an implementation-defined NTBS.