java - 是否建议在业务逻辑中进行不必要的错误处理？例如。空检查/百分比限制检查等

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
}

如果我们确定它永远不会为空，为什么我们需要这个空检查？ 这是一个好的做法吗？

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. 断言导致代码提前失败，并传达意图，而无需您输入永远不会到达的错误处理代码，也不会混淆代码覆盖工具
4. 文档或内联评论

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

public @Nonnull ObjectABC funcABC(){

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

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

与

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

Aren't we swallowing some fundamental issue by putting such checks?

根据经验，

1. 单元测试适用于检查一小段代码的行为。如果您不能为重要功能编写单元测试，那么根本问题是您不是 writing testable code .
2. 注释有助于向代码审阅者、维护者和自动化工具传达意图。如果您没有将这些工具集成到您的流程中，那么根本问题是您没有利用可用的代码质量工具。
3. assert 有助于仔细检查您的假设。如果您不能将断言散布到您的代码中并快速判断哪些被违反，那么您的根本问题是您没有一种快速的方法来针对代表性数据运行您的代码以解决问题。
4. 文档和内联注释(包括源代码控制注释)有助于在团队中传播有关系统的知识——确保团队中不止一个人可以解决代码任何部分的问题。如果它们经常丢失或不同步，那么潜在的问题是您在编写代码时没有考虑到维护者。

最后，design by contract是一种编程方法，许多人发现它对业务逻辑代码很有用。即使您不能说服您的团队采用特定的工具和实践，阅读 DbC 可能仍会帮助您推理和解释如何在您的代码库中实现重要的不变量。