1700439518
1700439519
//把阿拉伯数字翻译成中文大写数字
1700439520
1700439521
public static String toChineseNumberCase（int n）{
1700439522
1700439523
String chineseNumber=””；
1700439524
1700439525
switch（n）{
1700439526
1700439527
case 0：chineseNumber=“零”；
1700439528
1700439529
case 1：chineseNumber=“壹”；
1700439530
1700439531
case 2：chineseNumber=“贰”；
1700439532
1700439533
case 3：chineseNumber=“叁”；
1700439534
1700439535
case 4：chineseNumber=“肆”；
1700439536
1700439537
case 5：chineseNumber=“伍”；
1700439538
1700439539
case 6：chineseNumber=“陆”；
1700439540
1700439541
case 7：chineseNumber=“柒”；
1700439542
1700439543
case 8：chineseNumber=“捌”；
1700439544
1700439545
case 9：chineseNumber=“玖”；
1700439546
1700439547
}
1700439548
1700439549
return chineseNumber；
1700439550
1700439551
}
1700439552
1700439553
}
1700439554
1700439555
这是一个简单的转换类，并没有完整实现，只是一个金融项目片段。如此简单的代码应该不会有错吧，我们运行看看，结果是：2=玖。
1700439556
1700439557
恩？错了？回头再来看程序，马上醒悟了：每个case语句后面少加了break关键字。程序从“case 2”后面的语句开始执行，直到找到最近的break语句结束，但可惜的是我们的程序中没有break语句，于是在程序执行的过程中，chineseNumber的赋值语句会多次执行，会从等于“贰”、等于“叁”、等于“肆”，一直变换到等于“玖”，switch语句执行结束了，于是结果也就如此了。
1700439558
1700439559
此类问题发生得非常频繁，但也很容易发现，只要做一下单元测试（Unit Test），问题立刻就会被发现并解决掉，但如果是在一堆的case语句中，其中某一条漏掉了break关键字，特别是在单元测试覆盖率不够高的时候（为什么不够高？在大点的项目中蹲过坑、打过仗的兄弟们可能都知道，项目质量是与项目工期息息相关的，而项目工期往往不是由项目人员决定的，所以如果一个项目的单元测试覆盖率能够达到60%，你就可以笑了），也就是说分支条件可能覆盖不到的时候，那就会在生产中出现大事故了。
1700439560
1700439561
我曾遇到过一个类似的事故，那是开发一个通过会员等级决定相关费率的系统，由于会员等级有100多个，所以测试时就采用了抽样测试的方法，测试时一切顺利，直到系统上线后，财务报表系统发现一个小概率的会员费率竟然出奇的低，于是就跟踪分析，发现是少了一个break，此事不仅造成甲方经济上的损失，而且在外部也产生了不良的影响，最后该代码的作者被辞退了，测试人员、质量负责人、项目经理都做了相应的处罚。希望读者能引以为戒，记住在case语句后面随手写上break，养成良好的习惯。
1700439562
1700439563
对于此类问题，还有一个最简单的解决办法：修改IDE的警告级别，例如在Eclipse中，可以依次点击Performaces→Java→Compiler→Errors/Warnings→Potential Programming problems，然后修改‘switch’case fall-through为Errors级别，如果你胆敢不在case语句中加入break，那Eclipse直接就报个红叉给你看，这样就可以完全避免该问题的发生了。
1700439564
1700439565
1700439566
1700439567
[
上一页 ]
[ :1.700439518e+09 ]
[
下一页 ]