0

我有以下界面：

public interface ICalculationRule {
    public void calculate(EventBag eventBag);
}

我想提供一些方法来表明计算是否失败，什么更正确？

  • 添加throws Exception到方法签名
  • 制作calculate方法 boolean（true=成功，false-失败）
4

5 回答 5

2

这一切都取决于 

 " Is the error is expected or unexpected ? "
  • 将抛出异常添加到方法签名

如果在计算过程中发生意外情况。假设抛出异常。如果它应该在使用中处理 try catch 并且如果你的方法的调用者应该对此做出反应。然后添加抛出异常。

  • 使计算方法布尔值（真=成功，假 - 失败）

如果 Result NO 是预期会发生的事情，并且如果错误条件没有那么重要，并且调用者只是想知道成功或失败的结果。去吧。

也不要去通用异常，但要具体。

我也可以考虑让代表通知呼叫者成功或失败。

public interface Response {
   public void onSuccess();
   public void onFailure(Exception exception);  
}

我可以通过调用者和计算方法调用来寻找它的实现对象。并且在成功或失败时可以调用各自的委托，例如

public void calculation(Response response) { 
    Exception e = null;

    try {
        // Do something here
    } catch (IOException ioe) {
        e = ioe;
    }

    if(e == null) {
        response.onSuccess();
    } else {
        response.onFailure(e);
    }
}

希望这能引导你走向正确的方向:)

于 2012-05-01T06:39:39.877 回答
1

异常的优点是关心更多信息，而不仅仅是简单的布尔答案。如果您只需要是/否答案 - 返回布尔值，因为它会使代码更加简洁，但如果您需要更多细节，则会抛出异常。

但请确保有自己的例外而不是标准java.lang.Exception。界面总是很糟糕，而且是双重糟糕。

于 2012-05-01T06:33:38.317 回答
0

一般来说，我们不建议使用异常来处理逻辑过程。异常应该被视为真正的异常，并且仅在必须时发生。要抛出异常，它绝对比仅仅返回一个值花费更多的时间，而且，我相信正确标记一个有意义的返回值对于代码阅读器和采用者将来更有意义。但是，这是不可避免的，如果某个地方通过返回值指示难以处理，您可以使用抛出异常。

对于您的情况，以下选项应该是正确的选择。

  make calculate method boolean (true=success, false - failure)
于 2012-05-01T07:27:32.587 回答
0

  1. 您可以尝试抛出一个自定义的异常，它继承自RuntimeException错误和结果，因此接口的客户端不必明确。这有助于避免不需要的 try catch 块

  2. 您可以尝试发送一个捕获成功和失败的 Result 对象，而不是布尔响应，从而获得一个容器来在调用者和被调用者之间传递信息

于 2012-05-01T06:42:14.157 回答
-1

重要的是要理解声明一个Exception可能会被抛出，表示它必须由客户端代码处理。这意味着您作为方法的作者，不能让它通过。

另一方面，如果计算失败不是那么严重，可能是客户端代码的问题，也可能不是，您可以boolean按照您的说明返回，让客户端代码决定是否应该应用特殊处理。如果您认为客户端需要的信息不仅仅是 a boolean，您总是可以返回某种CalculationResult对象。

于 2012-05-01T06:41:39.643 回答