龙空技术网

(四)改掉这些坏习惯,还怕写不出健壮的代码?

一猿小讲 1182

前言:

眼前看官们对“bigdecimal判断是否为空”大体比较注重,兄弟们都想要剖析一些“bigdecimal判断是否为空”的相关知识。那么小编也在网上搜集了一些对于“bigdecimal判断是否为空””的相关资讯,希望咱们能喜欢,我们快快来了解一下吧!

Code Review 是一场苦涩但有意思的修行。

书接上篇,本次继续探讨一下,该如何写出健壮的代码?

编码时:看似顺眼,实则不然。

举个栗子:

String amount = request.getParameter("amount");// 校验金额小数点后最多两位小数BigDecimal a = new BigDecimal(amount);if (a.doubleValue() * 100 - Math.floor(a.doubleValue() * 100) != 0) {    System.out.println("交易金额错误");    // do something ... ...}

摘一段跑在生产环境上的代码,代码咋一看没啥问题,主要功能是获取请求参数;然后完成数据校验。

看似很顺眼,但是你细品,就会发现其中之奥秘,下面一起在本地跑跑代码,来分析一下到底会存在什么问题?

问题一:坑死人的 NPE

输入:null(当 amount 输入为空时)

输出:

Exception in thread "main" java.lang.NullPointerException  at java.math.BigDecimal.<init>(BigDecimal.java:806)  at PayController.main(PayController.java:300)

分析:

根据上面异常信息,见 BigDecimal 的源码第 806 行,如下图所示,很显然 BigDecimal 构造不会判断传入的 val 是否为空,所以会出现空指针异常。

目前没有出现问题,那只能算庆幸,不过终究是个定时炸弹。切记调用 BigDecimal 的构造时,请勿传入 null 值。

心声:身边老码农真真的排查了好长时间,问题场景与此类似,直接阻断了程序后续的流程。

问题二:同样是传入数字,结果咋就匪夷所思。

输入:

6666.66(当 amount 输入为 6666.66)

当 amount 输入为 6666.66 时,amount 的值校验通过。真的是看到的这个样子吗?换个数试试呗。

输入:

8888.88(当 amount 输入为 8888.88)

输出:

交易金额错误

分析:

容我拆解一下代码,当 amount 传入为 8888.88 时:

double d1 = a.doubleValue() * 100;double d2 = Math.floor(a.doubleValue() * 100);System.out.println(d1); // 输出:888887.9999999999System.out.println(d2); // 输出:888887.0System.out.println(d1 - d2); // 输出:0.9999999998835847

很显然, d1 - d2 的值 != 0,那么如下表达式的值则满足,会输出交易金额错误。

为什么呢?归根揭底是 double 运算时精度丢失而导致程序处理出错,虽然在 Java 中提倡用 BigDecimal 进行四则运算,但是上面的校验实现,貌似跟 BigDecimal 没有啥关系,到底该怎么解决呢?

无脑实现方式:

if (amount.contains(".") && amount.substring(amount.indexOf(".") + 1).length() > 2) {      System.out.println("校验失败 2");      // do something ... ...}

如上面代码段所示,直接判断传入的 amount 字符串小数点后面的位数就可以啦。

当然,仁者见仁智者见智,实现方式有很多,不去多深究。

编码时:时间转换也作祟

举个栗子:

public static long convertDaysToMilliseconds(int days) {    return 1000 * 3600 * 24 * days;}

分析:

1000 * 3600 * 24 * days 结果默认为 int 类型,最大值为 2147483647,如果超过 int 范围,则会出现截断,程序不会出错,但是结果却匪夷所思。

例如:

当 days 输入为 30 时,程序输出:-1702967296。

改进方式一:

改进方式二:

再举个栗子:

public static Date getDate(int seconds) {    return new Date(seconds * 1000);}

分析:当 seconds * 1000 值为 int 类型,当超过 int 最大值为2147483647 时,程序不会出错,但是结果却匪夷所思。

改进方式:

分享一下心声:

禁止使用 double 直接参与金额运算,会出现意想不到的结果。

浮点数采用“尾数+阶码”的编码方式,类似于科学计数法的“有效数字+指数”的表示方式。 二进制无法精确表示大部分的十进制小数。

—— 请自行科普,留作业。

禁止使用构造方法 BigDecimal(double)的方式把 double 值转化为 BigDecimal 对象。

BigDecimal(double)存在精度损失风险,在精确计算或值比较的场景中可能会导致业务逻辑异常。

如:BigDecimal g = new BigDecimal(0.1f); 实际的存储值为:0.10000000149

优先推荐入参为 String 的构造方法,或使用 BigDecimal 的 valueOf 方法,此方法内部其实执行了 Double 的 toString,而 Double 的 toString 按 double 的实际能表达的精度对尾数进行了截断。

—— 阿里开发手册

那些看似顺眼的代码,或者线上跑着的代码,未必就没问题,只是没有走到异常分支上去,随着时间的推移,定时炸弹迟早会爆,定期审查代码,以及充分的测试是非常的必要。寄语写最后

我等采石之人当心怀大教堂之愿景——《程序员修炼之道》。

好了,代码修炼的系列分享,本次就谈到这里,一起聊技术、谈业务、喷架构,少走弯路,不踩大坑。欢迎关注「一猿小讲」,会持续输出原创精彩分享,敬请期待!

标签: #bigdecimal判断是否为空 #doublevalueof 小数位数控制