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

问题描述：

假设我有一个像我应该在方法中捕获这个NumberFormatException吗？

void A(long input) { 

    ...... 

}

方法基本上，它运作良好，当输入是长还是能够成功转换其他类型的长。

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

void A(long input){ 

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

    } 

}

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

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

你的问题没有任何意义的措辞。 `输入'是一个很长的时间。这个NumberFormatException应该来自哪里？ – 2010-11-29 07:27:56

如果从另一个方法输入。输入是字符串“36000L”; – Joseph 2010-11-29 08:22:43

答

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

然而在你的情况下，由于该函数没有返回任何东西，调用者怎么知道发生了什么错误？如果没关系，那么捕捉可能会很好。如果它确实重要，那么传播异常是通知错误存在的好方法（除非函数签名被改变）。

答

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

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

答

如果方法接受long，那么方法本身就没有转换 - 在调用该方法之前，参数将被转换为被推入堆栈，并且您将无法捕获转换方法本身内的错误。

如果你想通过一个有参数的String，那么你会做自己的转换 - 并且要么需要捕获异常，要么抛出异常。无论哪种方式都可以同样有效，并且选择取决于您希望如何处理无效值。如果你只是抛出一个异常，说“这不是一个真正的数字”或什么的，那么你可能只是抛出异常。

答

有时，我们有99.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; 
    } 
}

答

的这个问题的答案取决于你的系统设计：但如果剩余的0.5％，可能会损害应用程序或数据库的一致性，它可能之前不好的事情发生更好的捕捉异常并抛出一个运行时异常。

如果是在Web UI进行数据类型的验证的责任，那么它是合理的下一级假设验证已经完成，并允许NumberFormatException传播。但是，尽管如此，服务器端代码应该捕获（意外）异常，记录它并生成适当的HTTP响应代码。
如果不是Web UI的责任来执行数据类型验证，那么下一个级别需要生成一个合适的（用户友好的）错误消息，并且使用户可以很容易地纠正它。（例如，在HTML实现的web UI仅将无法验证数据在任何程度。）

如果您的系统设计不明确指定了各种验证的责任属于，则设计有缺陷。

你也应该考虑是否是通过数字作为字符串，他们已经过验证后是一个好主意。这可能是必要的;例如如果这些图层位于独立的webapp容器中。但是，如果验证和业务逻辑都在同一个servlet，那么前者应传递一个int或long，而不是一个数字后面的String表示。

最后，如果任何理论上内部Web API都是实际上暴露，你至少应该做足够的验证，以保护它们免受黑客攻击。例如，如果面向用户的Web UI是HTML + Javascript，那么还必须有一个与之通信的公开的基于HTTP的API。黑客绕过你的GUI和谈话目录到HTTP API是一件简单的事情。所以HTTP API应该至少在必要的程度上验证请求以掩盖企图利用的漏洞。

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

相关推荐