业务逻辑中推荐不必要的错误处理吗？例如.空检查/百分比限制检查等

Question

我们通常会在业务逻辑中进行不必要的检查以避免失败.

例如.

1. public ObjectABC funcABC(){

      ObjectABC obj = new ObjectABC;
     ..........
     ..........
     //its never set to null here.
     ..........
     return obj; 
} 

ObjectABC o = funABC();

if(o!=null){
//do something
}

如果我们确定它永远不会为null,为什么我们需要这个null检查？这是一个好习惯吗？

2. int pplReached = funA(..,..,..);
   int totalPpl   = funB(..,..,..);

   funA() just puts a few more restriction over result of funB().


    Double percentage = (totalPpl==0||totalPpl<pplReached) ? 0.0 : pplReached/totalPpl;

我们需要'totalPpl<pplReached'检查吗？

问题是:我们不是通过进行此类检查来吞下一些基本问题吗？通过进行这些检查可以避免理想地显示的问题.

推荐的方式是什么？

Answer 1

想想你的观众.检查是值得的

1. 帮助你,程序员,检测错误,
2. 帮助其他程序员检测代码与您的代码相遇的错误,
3. 允许程序从错误输入或无效状态恢复,或
4. 帮助维护者避免以后引入错误.

如果null上面的检查不属于这些,或者有一个更简单的机制可以做同样的事情,那么就把它留下来.

更简单的机制通常包括,

1. 单元测试.
2. 向读者传达意图的注释,可以通过findbugs或类似工具进行检查
3. assert导致代码提前失败,并传达意图而不要求您输入永远不会达到的错误处理代码而不会混淆代码覆盖工具
4. 文档或内联注释

在这种情况下,我建议添加注释

public @Nonnull ObjectABC funcABC(){

将findbugs集成到您的构建过程中,并可能替换

if(o!=null){
//do something
}

同

assert o != null: "funcABC() should have allocated a new instance or failed."

我们不是通过这样的检查吞下一些基本问题吗？

根据经验,

1. 单元测试有助于检查一小段代码的行为.如果你不能为重要的函数编写单元测试,那么根本问题在于你没有编写可测试的代码.
2. 注释有助于向代码审阅者,维护者和自动化工具传达意图.如果您尚未将这些工具集成到流程中,那么根本问题在于您没有利用可用的代码质量工具.
3. asserts有助于仔细检查您的假设.如果您无法将断言汇集到您的代码中并快速告知哪些被侵犯,那么您的根本问题在于您没有快速的方法来针对代表性数据运行代码以解决问题.
4. 文档和内联注释(包括源代码控制注释)有助于在团队中传播有关系统的知识 - 确保团队中的多个人可以在代码的任何部分修复问题.如果它们经常丢失或不同步,那么潜在的问题是你不是在考虑使用维护者来编写代码.

最后,按合同设计是一种编程方法,许多人发现它对业务逻辑代码很有用.即使您无法说服您的团队采用特定的工具和实践,阅读DbC仍然可以帮助您推理并解释如何在代码库中强制执行重要的不变量.