我可以写一个类似于缩写函数模板的catch子句吗？

Question

在我的程序的顶部，我有一个异常处理程序。
它看起来像这样：

try{
    //majority of program
}
catch(...){
   Handle_All_Exceptions();
}


void Handle_All_Exceptions(){
   try{throw;}
   catch(TypeA const& e){Handle(e)       ;}
   catch(TypeB const& e){Handle(e)       ;}
   catch(TypeC const& e){Handle(e)       ;}
   catch(TypeD const& e){Handle(e)       ;}
   catch(...)           {Handle_Unknown();}

}

void Handle(TypeA const& e){
    //...
}
void Handle(TypeB const& e){
    //...
}
void Handle(TypeC const& e){
    //...
}
void Handle(TypeD const& e){
    //...
}
void Handle_Unknown(){
    //...
}

随着我获得更多的异常类型，
我想采取更通用的方法。
如何将通用编程应用于 Handle_All_Exceptions 函数？

---

在较新版本的C ++中，这样的事情会有可能吗？

catch(auto e){Handle(e)};
catch(...){Handle_Unknown();}

Answer 1

如果没有对语言及其异常系统进行重大更改，则无法实现。 虽然catch子句处理程序和函数参数看起来可能在语法上相似，但它们的工作方式完全不同。 考虑：

struct up {};
struct down { constexpr down(up) noexcept {} };

void func(down const&) {}
void except()
{
    try {
        throw up {};
    } catch(down const&) {}
}

int main()
{
    func(up {}); // fine
    except();    // exception `up` escapes
}

Coliru

换句话说， down const&参数将接受任何可转换为down东西，而down const& handler将绑定到down类型或类型的异常对象，公开派生自down 。

这里的最大区别是“可转换为”形式的关系可以采取多种形式。 在我们的例子中，我们使用的转换构造，但我们也能代替内部使用的转换操作符up 。 而'（公开，明确地）派生自'只能以一种简单的方式选择，并且只能在程序范围内的一个位置选择：无论何处定义派生类型。 当我们考虑单独的编译时，这很重要。 考虑以下程序：

// a.cpp

// defined in b.cpp
void throws() noexcept(false);

template<typename X>
concept bool Fooable = requires(X x) { x.foo(); }

int main()
{
    try {
      throws();

      // imaginary syntax for catching models of a concept
    } catch(Fooable const&) {}
}

// b.cpp

// defined in c.cpp
struct other;

struct model {
    void foo() {}
    other* foo(int) { return nullptr; }
    void bar() {}
};

void throws() noexcept(false)
{ throw model {}; }

// c.cpp omitted

编译b.cpp ，编译器无法知道a.cpp会问一个问题'你正在抛出的对象是x.foo() ？'。 它是否应该悲观地记录下这个事实（在现行规则下以同样的方式，“来自'关系，如果有的话，在某处记录）？ 它是否还应该记录model能够使用x.bar()的事实，即使完整程序不需要它？ 如果Fooable测试了x.foo(0)->baz()怎么办？ 如果other人被定义为表达有意义，那么何时，何时以及如何记录？ 注意model和other是如何单独定义的，并且每个都不知道（很多）关于另一个。

当然，你要求的并非完全不可能，但我希望我们能够同意它看起来与我们现在的系统完全不同，并且在它起作用之前需要付出很多努力。 根据当前规则，异常的泛型编程只能到目前为止，使用老式的类层次结构是阻力最小的路径。