根据C++引用，您可以通过以下方式新建对象：
MyClass * p1 = new MyClass;
或通过
MyClass * p2 = new (std::nothrow) MyClass;
第二个将返回一个空指针，而不是抛出异常。
然而，根据我的经验，我几乎看不到这个版本。
例如，谷歌不建议在他们的代码中使用exception，但正如我所看到的，他们也没有在Chromium中使用另一个版本。
有什么理由让我们更喜欢默认的而不是另一个？即使在一个没有使用异常的项目中？
--编辑--
后续问题：我应该检查malloc()的返回值吗？
相反，很多人建议检查malloc的返回值，有些人说是因为：
许多分配失败与内存不足无关。碎片化可能会导致分配失败，因为即使有足够的可用内存，也没有足够的连续空间。
这是真的吗？为什么我们在这种情况下对malloc()和new()有不同的处理？
然而，根据我的经验，我几乎看不到这个版本。
如果您可以在本地处理故障，则可以使用它（或者，等效地，从默认版本捕获异常）；也许是通过请求释放一些其他内存然后重试，或者通过尝试分配较小的内存，或者使用不需要额外内存的替代算法。
有什么理由让我们更喜欢默认的而不是另一个？
异常的一般原则是：如果你不能在本地处理它，那么在本地检查就没有意义了。与返回值不同，异常不能被忽略，因此不可能不顾一切地使用空指针。
即使在一个没有使用异常的项目中？
通常，内存不足的情况根本无法处理。在这种情况下，终止程序可能是最好的回应；这是对未处理异常的默认响应。因此，即使您不使用异常，在大多数情况下，默认的new可能是最好的选择。
我应该检查
malloc()的返回值吗？
是的：这是检查它是否成功的唯一方法。如果你不这样做，那么你最终可能会使用一个空指针，给出未定义的行为：通常是崩溃，但可能是数据损坏或其他奇怪的行为，以及长时间的调试会话，以（希望）找出问题所在。
为什么我们在这种情况下对
malloc()和new有不同的处理？
因为malloc强制我们检查返回值，而new为我们提供了侵入性较小的错误处理选项。
如果使用抛出版本，则不需要测试每个new调用的结果来判断它是成功还是失败。通常来说，在许多/大多数应用程序中，如果分配失败，您就不能做太多工作，只能退出/中止，如果您没有明确尝试/捕获，则异常会自动为您执行。
如果您使用nothrow版本，您可能会在应用程序中传播一个空指针，并在稍后崩溃/退出MUCH，这显然与内存分配完全无关，从而使调试更加困难。