getinteger方法

凌晨三点，我盯着控制台上那个跳动的红色异常——NullPointerException。这已经是本周第三次了，原因都一样：用户提交表单时，某个数字字段传了个空字符串。后端代码里躺着个老掉牙的Integer.parseInt(request.getParameter("age"))，一旦遇到空值，直接炸穿。

后来我翻遍项目里所有工具类，发现每个程序员都自己写过一个“安全”的整数解析方法。有人叫getInt，有人叫parseIntSafely，还有人干脆在try-catch里塞了个默认值0。五花八门，但没一个能统一处理“空字符串”“null”“非法字符”这三种情况。那个周末，我花了四个小时写了个getInteger方法，从此再没为这事加过班。

方法本身不复杂。先判空，再trim，然后正则过滤，最后才parseInt。但真正让我得意的是默认值的设计——不是固定返回0，而是允许调用者传入一个fallback。比如从配置文件读端口号，读不到就返回8080；从请求参数读年龄，非法就返回-1让上层校验。这比硬编码0灵活得多。

有个同事问我：“你写这么多if-else，不如直接用Apache Commons的NumberUtils.toInt，一行搞定。”他说的没错，但那是另一个问题：依赖库版本升级时，万一方法签名变了呢？万一团队里有人不知道这个库存在，又自己写了个重复的？我见过太多项目，因为“方便”引入了一堆工具类，结果代码里同时存在三种parseInt风格。

更关键的是，getInteger这个名字本身就在传达一种约定。它暗示“拿到整数，且拿不到时有个兜底”。新人看到方法名，不用翻实现就知道怎么用。后来我在团队规范里加了一条：所有外部输入的整数解析，一律走这个方法。三个月后，线上因为数字格式导致的异常减少了九成。

当然，这方法也有短板。比如它无法区分“用户没填”和“用户填了非法值”——两者都返回同一个默认值。如果业务需要区分，就得改签名，返回一个Optional。但大多数场景不需要这种精细度，默认值足够用。

写这段代码最大的收获不是技术本身，而是意识到：很多所谓“低级”的工具方法，恰恰是系统稳定性的基石。与其每次遇到异常就临时打补丁，不如花点时间沉淀一个公共方法，把边界情况一次性处理干净。代码这东西，偷懒一时爽，填坑火葬场。

现在每当我看到新项目里有人又写了个try { return Integer.parseInt(x); } catch (Exception e) { return 0; }，我就想笑。不是笑他菜，是笑我自己当年也这么干过。直到被线上告警打脸，才学会把“防御”写进方法名里。