[Voted into the WP at the February, 2012 meeting; moved to DR at the October, 2012 meeting.]

Proposed resolution (February, 2010):

This issue is resolved by the resolution of issue 388.

Notes from the October, 2009 meeting:

The CWG agreed that matching the exception object with a handler should, to the extent possible, mimic ordinary reference binding in cases like this.

Given the following example:

    int f() {
        try { /* ... */ }
        catch(const int*&) {
            return 1;
        }
        catch(int*&) {
            return 2;
        }
        return 3;
    }

can f() return 2? That is, does an int* exception object match a const int*& handler?

According to 14.4 [except.handle] paragraph 3, it does not:

A handler is a match for an exception object of type E if

• The handler is of type cv T or cv T& and E and T are the same type (ignoring the top-level cv-qualifiers), or

• the handler is of type cv T or cv T& and T is an unambiguous public base class of E, or

• the handler is of type cv1 T* cv2 and E is a pointer type that can be converted to the type of the handler by either or both of

  • a standard pointer conversion (7.3.12 [conv.ptr]) not involving conversions to pointers to private or protected or ambiguous classes

  • a qualification conversion

• the handler is a pointer or pointer to member type and E is std::nullptr_t.

Only the third bullet allows qualification conversions, but only the first bullet applies to a handler of reference-to-pointer type. This is consistent with how other reference bindings work; for example, the following is ill-formed:

    int* p;
    const int*& r = p;

(The consistency is not complete; the reference binding would be permitted if r had type const int* const &, but a handler of that type would still not match an int* exception object.)

However, implementation practice seems to be in the other direction; both EDG and g++ do match an int* with a const int*&, and the Microsoft compiler issues an error for the presumed hidden handler in the code above. Should the Standard be changed to reflect existing practice?

(See also issue 388.)