Question

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

让我们假设服务包中有下一个代码。

throw new MyException(object);

MyException类：

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

public Object getObject() {
    return object;
}

稍后，让我们说，在GUI中我们必须处理服务中抛出的异常。我们只是捕获一个异常，并希望访问构造函数中传递的对象。这有效。但从风格的角度来看它是否正确？

使用getObject（）是正确的方法吗？

Answer 1

我想说这取决于你在getObject做了些什么。如果您只是用它来报告错误或管理异常的恢复，那么这没有任何问题。我会传递比对象更具体的东西。例如，我可能会提供有关错误原因的异常信息，并捕获可能有助于解决错误的任何有用信息。

另一方面，如果您正在使用此对象继续控制流的一些正常分支，那么这不会被视为异常的正常使用！重复显而易见的是，异常情况仅适用于特殊情况，仅此而已。如果你正在与他们做其他事情，那通常是个坏主意。

如果您正在使用异常捕获稍后处理的结果，那么这是一个糟糕的设计气味。看看重构你的代码，把这些对象写到商店以便以后处理，或者其他一些。不要滥用例外。

Answer 2

通常，是的，将数据添加到异常对象中可能对处理异常的代码有用。

但是，返回getObject()的{{1}}方法过于通用 - 方法的名称，最好也是对象的类型应该特定于异常 - 创建多个异常类，如果必要的，然后你可以在catch块中区分它们。

最后，这种事情可能被滥用于常规控制流程。我不同意标准的教条，这本身就是“邪恶的”＃34; - 例外是控制流机制。但是他们认为可维护性不好，因为它隐含地连接了一些代码。因此，只有当你真的需要一种方法将控制流传递给调用堆栈的几个级别并且已经考虑了替代方案时，才应该使用它。

Answer 3

与往常一样，这取决于您的系统结构和您想要达到的目标，但IMO这是一种可接受的方式。

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

Answer 4

捕获异常的类取决于封装在异常中的对象的（静态）类。最小化依赖关系通常是个好主意。这就是为什么我不会将组件内部的类封装到异常中。只有当异常和封装类属于同一个组件时，我才会将组件的公共类封装在异常中。