什么是当它的一些准则 不是 必要的检查空？

到目前为止，我一直在处理的许多继承代码都带有null检查广告。对琐碎的函数进行空检查，对声明非空返回的API调用进行空检查，等等。在某些情况下，空检查是合理的，但在许多地方，空值不是合理的期望。

我听到过许多参数，从“您不能信任其他代码”到“始终防御性地编程”再到“直到语言保证我没有非空值，我总是要检查”。在某种程度上，我当然同意其中的许多原则，但是我发现过多的null检查会导致其他通常违反这些原则的问题。顽强的null检查真的值得吗？

通常，我观察到带有过多空值检查的代码实际上质量较差，而不是质量较高。许多代码似乎都集中在null检查上，以至于开发人员已经忽略了其他重要特性，例如可读性，正确性或异常处理。特别是，我看到很多代码都忽略了std
:: bad_alloc异常，但是对进行了空检查new。

在C
++中，由于解除引用空指针的行为具有不可预测的特性，因此我在某种程度上理解了这一点。在Java，C＃，Python等中，可以更轻松地处理null取消引用。我刚刚看过一些不良示例（例如，警惕的null检查）还是真的有什么用？

尽管我主要对C ++，Java和C＃感兴趣，但该问题旨在与语言无关。

我见过一些看起来 过分 的空检查示例，包括：

此示例似乎是对非标准编译器的解释，因为C 规范说失败的新代码会引发异常。除非您明确支持不兼容的编译器，否则这有意义吗？这是否 任何
像Java或C＃（甚至C / CLR）托管的语感？

try {
   MyObject* obj = new MyObject(); 
   if(obj!=NULL) {
      //do something
   } else {
      //??? most code I see has log-it and move on
      //or it repeats what's in the exception handler
   }
} catch(std::bad_alloc) {
   //Do something? normally--this code is wrong as it allocates
   //more memory and will likely fail, such as writing to a log file.
}

另一个示例是在处理内部代码时。特别是，如果是一个可以定义自己的开发实践的小组，这似乎是不必要的。在某些项目或旧代码中，信任文档可能并不合理……但是对于您或您的团队控制的新代码，这真的有必要吗？

如果您可以查看并可以更新的方法（或者可以大喊大叫的开发人员）已签有合同，那么是否仍然需要检查null？

//X is non-negative.
//Returns an object or throws exception.
MyObject* create(int x) {
   if(x<0) throw;
   return new MyObject();
}

try {
   MyObject* x = create(unknownVar);
   if(x!=null) {
      //is this null check really necessary?
   }
} catch {
   //do something
}

开发私有或其他内部函数时，当合同仅要求非空值时，是否真的需要显式处理空值？为什么空检查比断言更可取？

（很明显，在您的公共API上，空检查至关重要，因为不正确地使用API​​会对用户大吼大叫是不礼貌的）

//Internal use only--non-public, not part of public API
//input must be non-null.
//returns non-negative value, or -1 if failed
int ParseType(String input) {
   if(input==null) return -1;
   //do something magic
   return value;
}

相比：

//Internal use only--non-public, not part of public API
//input must be non-null.
//returns non-negative value
int ParseType(String input) {
   assert(input!=null : "Input must be non-null.");
   //do something magic
   return value;
}