Java中NumberFormatException异常处理

P粉602998670 2026-01-11 00:00:00 次阅读

NumberFormatException在字符串格式非法时抛出，如空串、纯字母、多余空格、Unicode零宽字符或超范围数值；应通过trim()校验、null检查及try-catch或Optional封装安全转换。

NumberFormatException是什么时候抛出的

当用 Integer.parseInt()、Long.parseLong()、Double.parseDouble() 这类静态解析方法尝试把一个非法格式的字符串转成数字时，JVM 就会直接抛出 NumberFormatException。它不是运行时偶然出错，而是输入本身就不满足数字语法——比如空字符串、纯字母、带多余空格、含 Unicode 零宽字符、或超出目标类型的取值范围（如 "2147483648" 转 int）。

怎么安全地做字符串转数字

别让程序在解析失败时崩溃，得提前兜底。核心思路是：先校验再转换，或者用 try-catch 捕获并提供默认值或错误提示。

对简单场景（如表单输入），用 try-catch 最直接：

String input = "123abc";
int value;
try {
    value = Integer.parseInt(input);
} catch (NumberFormatException e) {
    value = 0; // 或抛自定义异常、记录日志、返回 Optional.empty()
}

若需复用校验逻辑，可封装工具方法，避免重复写 try-catch：

public static Optional parseIntSafe(String s) {
    if (s == null || s.trim().isEmpty()) return Optional.empty();
    try {
        return Optional.of(Integer.parseInt(s.trim()));
    } catch (NumberFormatException e) {
        return Optional.empty();
    }
}

Java 17+ 可考虑 Integer.decode()，它支持十六进制前缀（如 "0xFF"），但依然会抛 NumberFormatException，不能替代校验。

常见踩坑点：trim() 和 null 检查容易被忽略

很多 NumberFormatException 其实源于肉眼难辨的空白字符，比如首尾空格、全角空格、或不可见控制符（如 \u200B）。不调用 trim() 就直接解析，" 42 " 会失败；传入 null 则必然触发异常——parseInt(null) 不会返回 0，而是立刻抛错。

永远在 parse 前检查 s == null 或 s.isEmpty()
trim() 是低成本高收益操作，建议无条件加上
不要依赖前端/上游“保证输入干净”——网络请求、文件读取、数据库字段都可能混入脏数据

性能与替代方案：什么时候不该用 parseInt

如果高频解析且输入基本可信（如内部配置、枚举序号），parseInt 没问题；但若大量不确定输入（如用户评论里的数字提取），频繁抛异常会影响性能——异常创建栈信息开销大。

正则预筛：用 s.matches("-?\\d+") 快速过滤纯整数字符串（注意不支持科学计数法和小数）
Apache Commons Lang 的 NumberUtils.toInt(s, defaultValue) 内部已处理 null/空/异常，适合快速替换
需要解析带单位的字符串（如 "1.5GB"）或容忍模糊格式，就该用专门的解析器，而不是硬塞给 parseDouble