3

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

让我们假设在服务包的某个地方有下一个代码。

throw new MyException(object);

MyException 类：

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

public Object getObject() {
    return object;
}

然后，假设在 GUI 中，我们必须处理服务中抛出的异常。我们只是捕获了一个异常并想要访问构造函数中传递的对象。这行得通。但从风格的角度来看，它是正确的吗？

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

4

4 回答 4

2

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

另一方面，如果您使用这个对象来继续控制流的一些正常分支，那么这不会被认为是对异常的正常使用！再说一遍，例外是针对特殊情况，仅此而已。如果您要与他们一起做其他事情，那通常是个坏主意。

如果您使用异常来捕获稍后要处理的结果，那么这是一种不好的设计气味。考虑重构您的代码以将这些对象写入存储以供以后处理，或者诸如此类。不要滥用异常。

于 2012-05-11T08:45:41.217 回答
0

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

但是，getObject()返回 anObject的方法过于通用 - 方法的名称以及对象的类型应该特定于异常 - 如果需要，请创建多个异常类，然后您可以在 catch 块中区分它们。

最后，这种东西可能会被滥用于常规控制流。我不同意这本质上是“邪恶”的标准教条——异常是一种控制流机制。但它们不利于可维护性，因为它隐式地连接了代码片段。因此，仅当您确实需要一种方法将控制流向上传递到调用堆栈的多个级别并且已经认真考虑过替代方案时，才应该使用它。

于 2012-05-11T08:50:53.597 回答
0

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

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

于 2012-05-11T08:51:42.250 回答
0

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

于 2012-05-11T08:53:37.893 回答