Java：抛出异常

Question

在抛出异常时将对象传递给构造函数是个好主意吗？

假设在服务包中有如下代码。

throw new MyException(object);

MyException类：

Object object;
public MyException(Object object) {
    super();
    this.object = object;
}

public Object getObject() {
    return object;
}

假设我们在GUI中处理服务中抛出的异常。我们捕获异常并希望访问构造函数中传递的对象。这是可行的，但从风格的角度来看，是否正确呢？

使用getObject()是正确的方法吗？

- positiveAlex

---

我需要将这个对象放入一个队列中，以便稍后处理。 - positiveAlex

Answer 1

我觉得这取决于你如何使用getObject。如果你只是用它来报告错误或处理异常恢复，那就没有什么问题。我会传递比对象更具体的内容。例如，我可能会给异常提供有关错误原因的信息，并捕获可能有助于解决错误的任何有用信息。

另一方面，如果你正在使用此对象来继续某个正常的控制流程，那么这将不被视为异常情况的正常使用！重申一遍，异常只适用于异常情况，不能滥用。如果你正在做其他事情，那通常是一个坏主意。

如果你正在使用异常来捕获稍后要处理的结果，那就是一个糟糕的设计味道。查看重构你的代码，将这些对象写入存储器以便稍后处理，或进行类似操作。不要滥用异常。

- Jeff Foster

---

第一部分是Effective Java #63推荐的 :-) - assylias

@Perry：在我看来，它不是“邪恶的”，而是“糟糕的”，只有在你确信其他选择更糟糕时才这样做。 - Michael Borgwardt

@MichaelBorgwardt 这是关于"X害处论"的争议之一。 - Jeff Foster

@Jeff：“Goto considered harmful”反对了一种广泛传播和接受的做法。在常规控制流程中使用异常并不是一种广泛接受的做法。将其谴责为“邪恶”似乎更像是重复教条而已。 - Michael Borgwardt

@MichaelBorgwardt 我删掉了"evil"这个词。在文本中，它的意思比我本想的更强烈（想象一下《奥斯汀·鲍尔的间谍大作战》中的邪恶博士说出这个词）。 - Jeff Foster

Answer 2

一般来说，将可能对处理异常的代码有用的数据添加到异常对象中是一个好习惯。

然而，返回一个返回类型为Object的getObject()方法过于通用 - 最好将方法名称和最好也包括对象类型指定为特定于异常 - 如果需要，可以创建多个异常类，然后在catch块中区分它们。

最后，这种做法可能会被滥用以进行常规控制流。我不同意标准教条认为这本质上是“邪恶”的观点 - 异常确实是一种控制流机制。但是，由于它隐式地连接了代码片段，因此对可维护性不利。因此，只有在确实需要一种将控制流传递到调用堆栈的多个级别并且已经深思熟虑了替代方案的情况下才应使用它。

- Michael Borgwardt

---

我只是在示例中使用了“对象”来描述问题。实际上，真正的代码更具体。 - positiveAlex

Answer 3

一如既往，这将取决于您的系统结构和想要实现的目标，但在我看来，这是一个可行的方法。

事实上，这是默认异常 API 处理错误消息和原因的方式，将它们作为构造函数参数传递（请参见 Exception 构造函数 API 文档），以便稍后处理。

- Tomas Narros

Answer 4

捕获异常的类取决于封装在异常中的对象的（静态）类。最好尽量减少依赖关系。因此，我不会将组件内部的类封装到异常中。只有当异常和封装的类属于同一组件时，才会将组件的公共类封装在异常中。

- Oswald