Question

假设我有像

这样的方法

void A(long input) {

  ......

}

基本上，当输入很长或者可以成功将其他类型转换为long时，它可以正常工作。

但是，当一些错误的数据输入时，会抛出NumberFormatException。所以一个强大的方法应该是

void A(long input){

   try{
       ...
   }catch(NumberFormatException e){

   }

}

然而，一些开发人员认为该项目是一个BS应用程序。所以输入是从web ui传递的。所以它可以确认输入是有效的。并且不需要处理此异常。

但我认为这是必须的。你怎么看？谢谢。

Answer 1

如果方法接受long，则方法本身内没有转换 - 在调用方法之前，参数将被转换为压缩到堆栈，并且您将无法捕获方法本身内的转换错误。

如果你想传递一个带有参数的String，那么你将进行自己的转换 - 并且需要捕获异常或让它被抛出。两种方式都可以同样有效，选择取决于您希望如何处理无效值。如果你只是要抛出一个说“这不是一个真正的数字”的异常，那么你也可以抛出异常。

Answer 2

是否在函数内捕获异常确实是一种选择。功能规范有帮助。

但是，在你的情况下，由于函数没有返回任何内容，调用者如何知道发生了错误？如果没关系，那么捕捉可能没问题。如果它确实重要，那么传播异常是通知错误存在的好方法（除非函数签名被更改）。

Answer 3

我认为最好有一个永远不会使用的try-catch块而不需要它。输入传递给Web-UI的事实意味着将来可以修改任何验证逻辑。

但是，您需要做的是确保向用户通知错误。

Answer 4

有时，我们99.5％肯定在一段代码中不会出现异常情况。但是如果剩下的0.5％会损害应用程序或数据库的一致性，那么捕获异常并在发生错误之前抛出运行时异常可能会更好：

private void String(String validatedStringWithALongValue) {
  try {
     long l = Long.parseLong(validatedStringWithALongValue);
     // ... do what has to be done
  } catch (NumberFormatException oops) {
     Exception e = new RuntimeException(oops);
     log.error("Bad news - validation failed or has been bypassed", e);
     throw e;
  }
}

Answer 5

这个问题的答案取决于您的系统设计。

如果Web UI负责执行数据类型验证，则下一级别假设已完成验证并允许NumberFormatException传播是合理的。但是，在某些时候，服务器端代码应该捕获（意外）异常，记录它并生成适当的HTTP响应代码。
如果Web UI不负责执行数据类型验证，则下一级需要生成合适的（用户友好的）错误消息，并使用户可以轻松纠正它。（例如，以HTML格式实现的Web UI无法在任何程度上验证数据。）

如果您的系统设计没有明确说明各种验证的责任在哪里，那么设计是有缺陷的。

您还应该考虑在验证数字后将数字作为字符串传递是否是个好主意。这可能是必要的;例如如果图层位于单独的webapp容器中。但是，如果验证和业务逻辑位于同一个servlet中，那么前者应该将int或long而不是String表示的数字传递给后者。

最后，如果任何一个名义上的内部网络api实际上暴露了，你至少应该做足够的验证来保护它们免受黑客攻击。例如，如果面向用户的Web UI是HTML + Javascript，那么还必须有一个与之通信的公开的基于HTTP的API。对于黑客来说，绕过GUI并将目录转换为HTTP API是一件简单的事情。因此，HTTP API应该至少在必要的范围内验证请求以阻止尝试的漏洞利用。

我应该在方法中捕获此NumberFormatException吗？

5 个答案: