动态继承的设计模式

Question

以下是我要做的，我不知道该找什么，也不知道该如何设计：

我正在为一个应用程序开发一个异常层次结构。作为这一点的一部分，有些异常有时是致命的，有时是可恢复的——特定实例是致命的还是可恢复的，在运行时由异常本身决定。为了便于组织，我希望能够做一些类似（我在python中工作）：

try:
    mightThrowAnException()
except RecoverableException:
    handleThisException()

然后我会有类似的东西：

^{pr2}$

其中MyException可以将fataxception或RecoverableException作为基类，具体取决于构造函数中发生的情况。在

我知道我可以有两个独立的异常MyFatalException和{}，然后在代码中引发其中一个或另一个，但是对于不同类型的错误，会有很多不同的异常，这些异常可能会从代码的多个位置引发，异常必须做一些事情，比如检查错误日志来确定这个实例是否应该是致命的，所以我认为将所有这些代码放入异常处理程序本身是有意义的。在

所以有几个问题：

1. 考虑到我想做的事情，这是一个好方法吗，还是有更好的设计来处理这类事情？在
2. 我读过关于类工厂的文章，但是我没有看到用这种方法动态更改基类的简单方法，我考虑过的其他事情是元类或重写exception的__new__()方法，我不太确定这三种方法的优缺点是什么。这些都是正确的方法还是我还需要别的方法？在

Answer 1

我的建议是将异常的内容与其含义分离开来。同一个例外在不同的地方可能有不同的含义！在

您的问题建议将异常转换为具有高级功能（如检查日志）的“感知”对象。但这并不是特例。尽可能多地提供有关对象的轻量级数据。捕捉代码就是这样做的，正如我上面所说的，完全可以想象某些异常将在某个地方以某种方式处理，而在另一个地方以另一种方式处理。在

Answer 2

如果无法将特定异常归类为致命的或可恢复的，我可能会使用属性来确定异常是否致命。在

class MyBaseException(Exception):
    def __init__(self, ..., fatal=True):
        self.fatal = fatal

class MyException(MyBaseException):
    ...

try:
    do_something_that_raises()
except MyBaseException, e:
    if e.fatal:
        logging.error(e)
        raise
    else:
        recover_somehow(e)

然而，异常的提出者可能不应该告诉侦听器异常是否致命。他们可以处理被认为是致命的异常。异常的目的是声明出了问题，然后让潜在用户确定他们是否可以从中恢复。在