动态继承的设计模式

Question

这就是我想要做的，我不确定要寻找什么或设计它的正确方法是什么：

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

try:
    mightThrowAnException()
except RecoverableException:
    handleThisException()

然后我会执行类似的操作：

class MyException(...):
    ...

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

我知道我可以有两个单独的异常 MyFatalException 和 MyRecoverableException，然后在代码中引发一个或另一个异常，但是对于不同类型的异常，将会有很多不同的异常。错误，可能会从代码中的多个位置引发，并且异常必须执行一些操作，例如检查错误日志以确定此实例是否应该是致命的，因此我认为将所有这些代码放入异常处理程序本身。

所以有几个问题：

1. 考虑到我想做的事情，这是一个好方法吗？或者对于此类事情是否有更好的设计？
2. 我读过有关类工厂的内容，但我没有看到用这种方法动态更改基类的简单方法，我考虑过的其他事情是元类或覆盖表达式的 __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)

然而，异常的引发者可能不应该告诉监听者异常是否是致命的。他们也许能够处理被视为致命的异常。异常的目的是声明出现了错误，然后让潜在用户确定是否可以从中恢复。