0
点赞
收藏
分享

微信扫一扫

Boolean.getBoolean问题记录


不喜,勿喷。

概述

看过源码后,就能清楚明白,很简单的一个问题,本文记录一下。幸好在发布上线之前,自己在本地自测时,发现这个问题并修复。非常简单的代码,简单到自以为是,根本不需要验证,结果啪啪啪打脸。但若上线后,将是不可预知的损失与后果。告诫自己,一定要自测自测自测。

场景

​queryTo​​​是一个​​Map<String, Object>​​​,里面存有一个Boolean类型的数据键​​key=cacheApi​​,想要拿到这个键的值(布尔值),根据这个布尔类型的数据判断走哪一个分支的逻辑。不同分支的逻辑差别十万八千里,所以此行代码实际上很重要。

想都没有想,直接写下如下方法:

Boolean.getBoolean(queryTo.get("cacheApi").toString());

代码就这么放着,没提交没上线。

后面在验证流程逻辑时发现不对劲,才知道这一行代码有问题,于是断点调试,截图如下:

Boolean.getBoolean问题记录_数据


WTF??明明是true,为啥会得到false?只能看源码

Boolean.getBoolean问题记录_数据_02


继续:

Boolean.getBoolean问题记录_数据_03


源码如下:

Boolean.getBoolean(queryTo.get("cacheApi").toString());

public static boolean getBoolean(String name) {
boolean result = false;
try {
result = parseBoolean(System.getProperty(name));
} catch (IllegalArgumentException | NullPointerException e) {
}
return result;
}

public static boolean parseBoolean(String s) {
return ((s != null) && s.equalsIgnoreCase("true"));
}

所以问题的核心在于​​System.getProperty(name)​​​,即​​System.getProperty("true")​​​,返回​​null​​。

至于源码为何要如此设计,想不通,不能理解。

解决方案很简单:

MapUtils.getBoolean(queryTo, "cacheApi");

结论

切莫自以为是,须善用工具类。


举报

相关推荐

0 条评论