处理NumberFormatExeption的最佳做法

我想知道处理NumberFormatException的最佳方法是什么？处理NumberFormatExeption的最佳做法

A NumberFormatException每当用户传递一个空字符串时，都会在我的代码中被抛出。有多种方法可以处理这个问题，但我不确定最佳方法是什么？

这里是我的代码是现在：

if(result != null) { 
    String [] values = result.trim().split(","); 
    // This is where the NumberFormatException occurs 
    long docId = Long.parseLong(values[0]); 
    //There is more to the code but the rest is unnecessary :) 
    break; 
}

我应该避免NumberFormatException的一起通过检查values[0]是在解析之前是空的？所以这样的事情：

if(result!= null) { 
    String [] values = result.trim().split(",");   
    if("".equals(values[0]) { 
     // This method returns void hence the empty return statement. 
     return; 
    } 
    long docId = Long.parseLong(values[0]); 
    break; 
}

或者我应该捕捉异常，如果它发生？

if(result!= null) { 
    String [] values = result.trim().split(",");   
    try{    
     long docId = Long.parseLong(values[0]); 
    } catch (NumberFormatExeption e) { 
     LOGGER.warn("Exception in ThisClass :: ", e); 
     return; 
    } 
    break; 
}

或者还有另一种方法，你推荐？

来源

2016-12-29 robben

也许这是类似的：http://stackoverflow.com/questions/4410107/what-is-the-proper-way-to-handle-a-numberformatexception-when-it-is-expected –

这不是一个重复！我正在寻求最佳做法。请重新打开@TimBiegeleisen这个问题。 – robben

同意。这个问题不是那个问题的重复。 –

最简单的方法是赶上NumberFormatException。

你选择的有两个问题：

这是可能的，你会得到的东西，既不是一个数字或一个空字符串。也可以得到一个对于int来说太大的整数。如果发生这种情况，那么您的修复程序不起作用。
A return在switch语句的中间可能会让你的代码更难理解。根据具体情况，这个可能是的一个问题。

如果你决定走下来避免NumberFormatException所有可能情况的路径，那么你需要检查所有可能的可解析的整数。这可以通过使用正则表达式... modulo来完成，在正则表达式中检查对于int（或long）太大的整数是非常混乱的。

在这种情况下，我的建议是让异常发生，并捕捉/处理它们。除非.....

如果空字符串是共同情况下，那么这将是更有效地对付他们作为特殊情况。其他不可解析的输入也一样。效率是否足以保证额外的复杂性取决于环境。
如果其他“差多少”的情况下是完全意想不到的，它可能是适当的不手柄NumberFormatException，允许异常中止请求/应用程序崩溃，然后处理追查坏的来源数据作为维护问题。（这也取决于上下文...显然。）

上处理NumberFormatExeption

在此背景下

最佳实践， “最佳实践” 是一个矛盾。

来源

2016-12-29 02:15:33

谢谢！我建议不捕捉NFE的原因是因为我读过，捕获运行时异常是不希望的，即你应该避免它发生。 – robben

此外，你是什么意思，“这是一个问题在返回的catch块”？而且，是的，我们注意到非常大量的空字符串导致NFE – robben

*“我读取捕捉运行时异常”* - 听起来不对。当然，作为一般性陈述是错误的。捕捉并从'RuntimeException'恢复是错误的，尽管...因为你无法知道你将捕捉什么异常，是什么引起它，以及如何处理它。 –

第一种方法不能处理各种情况，因此我更喜欢使用第二种方法。

来源

2016-12-29 01:24:07 devneko

NFE可能由于各种原因而被抛出，而不仅仅是提供空字符串的用户。第二种方法处理这些。第一种方法仍然可以抛出一个NFE！

此外，恕我直言，这是用户提供的数据的简单数据验证。所以你可能想要给用户一个适当的错误信息。（WARN日志可能是不够的）

在这种情况下，异常可能是一种合适的方式来处理它，即或者将NFE包装成更好的类似ValidationException的sort。（你可能会有其他有效性检查：在一定范围内解析长期等）

而且我不认为有必要尝试避免通过使用正则表达式获取NFE解析长。不值得努力。

来源

2016-12-29 02:16:14

谢谢！我建议不捕捉NFE的原因是因为我读过，捕获运行时异常是不希望的，即你应该避免它发生。 – robben

这取决于例外，真的。是的，许多RuntimeExceptions指示程序中存在一个错误（如着名的NullPointerException），但在NFE的情况下，设计者可能认为将它作为检查异常负担过重。 –

如果您的应用程序比偶尔分析数字更多，您应该创建一个类来标准化解析 - 也可能还会违约 - 行为。

一般有两种方法来解析无效数据：

快速失败 - 允许引发异常&传播，用一个有意义的诊断信息。业务逻辑将被终止。
宽容 - 提供错误输入时使用默认值，最好记录警告。业务逻辑将以默认值运行。（你的问题意味着你靠在这种方法。）

没有数据（空/空/空字符串）可以通过以下三种方式之一进行处理：

空意味着缺席一个值（较少，导致空），的
空意味着默认值，（最常见）
空是错误的。

长话短说，最常见的方法是提供一个parseInt (String s, int defaultVal)功能是宽容和答案都空白&错误作为默认值。

public static int parseInt (String s, int defaultVal) { 
    if (StringUtils.isBlank(s)) 
     return defaultVal; 

    try { 
     return Integer.parseInt(s); 
    } catch (NumberFormatException x) { 
     log.warn("unparseable integer value: "+s+", using default", x); 
     return defaultVal; 
    } 
}

这可以放在解析工具类或其他合适的位置。最后一个注释：解析用于配置&输入数据，但依赖注入框架（如Spring和CDI）现在可以为您执行大多数配置解析。然而，解析仍然与输入数据相关。

来源

2016-12-29 02:38:46

感谢您的帮助！ – robben

处理NumberFormatExeption的最佳做法

回答

相关问题