为什么许多语言将异常对象视为一等公民？

Question

当我们得到一个实际上是异常的对象时，我们可以对它们做任何事情，就像我们的语言中对常规对象所能做的那样。我们可以将它们作为参数传递，我们可以将它们存储在某个集合中，最糟糕的是，我们可以将它们作为方法的结果返回！

因此，有人可能会像这样编写臭气熏天的代码：

public Exception doSomethingCritical()
{
    Exception error = null;

    try
    {
        ...
    }
    catch (Exception e)
    {
        // maybe at least here is the logging of the error if we are lucky
        error = e;
    }
    return error;
}

所以问题是，为什么异常对象的概念在许多面向对象语言中是一等公民？如果我们只在允许异常对象的语言中使用有限的结构(比如抛出)，可能会更好。

Answer 1

我的观点是。

我认为你混淆了两个不同的东西:异常和抛出异常。

异常抛出是一个带外过程，它允许您通过优先的横向通道抛出对象。这个对象可以通过异常捕获机制被拦截和处理。

异常只是您可以(优先)通过异常抛出带外通道抛出的一个对象。当然，此通道可以包含抛出的对象的接口的必要条件，也可以是由Exception类接口满足的必要条件。

你正在以另一种方式看待这个问题。的确，您可以做一些可怕的事情，但除了是在带外通道中抛出的首选对象之外，Exception对象并没有什么特别之处。

Answer 2

将异常视为特殊情况，并只允许有限的异常功能的问题是，最终每个好的程序都需要对异常做一些事情，无论是全局错误处理程序还是适当处理异常的有限项。通过使一等公民例外，有许多好处，例如：

允许异常子类化的

• 。这对于异常处理来说是非常有价值的，因为处理异常的代码可以缩小它们的范围，只处理它们知道如何处理的异常。我甚至可以说，任何只捕获“异常”的非全局异常处理例程都可能做错了。
• 将数据与异常一起传递。如果您在catch逻辑中唯一知道的是发生了异常，那么异常就不是很有用。堆栈跟踪、消息甚至某些异常类型的自定义数据对于识别和解决导致异常的问题非常有价值。
• 创建使用OOP本身的错误处理例程。如果异常不能作为对象传递，那么你就不能拥有一个处理异常的库--至少不是一个写得很好的库。

除此之外，没有办法像你上面发布的那样防止糟糕的异常处理。即使一个异常不是一等公民，也没有办法阻止开发人员吃掉任何和所有的异常并继续他们的快乐之路(至少，不会从根本上打破我们对异常的看法)。

Answer 3

我从来没有见过你用过的那个例子。我看不出不允许人们返回异常会对概念上很差的代码有多大的影响--比较

public int doSomethingCritical()
{
    int error = 0;

    try
    {
        ...
    }
    catch (Exception e)
    {
        // maybe at least here is the logging of the error if we are lucky
        error = E_SOMETHINGBAD;
    }
    return error;
}

然而，如果您创建了一种新的“事物”用于异常，而该“事物”与对象不同，则存在设计和学习开销的缺点。