当构造函数无法完成所述对象的构造时，它应该抛出异常。

例如，如果构造函数应该分配1024 KB的ram，但它没有这样做，它应该抛出一个异常，这样构造函数的调用者就知道对象还没有准备好使用，并且在某个地方存在需要修复的错误。

半初始化和半死亡的对象只会引起问题和问题，因为调用者确实没有办法知道。我宁愿让我的构造函数在出错时抛出一个错误，而不是不得不依赖编程来运行返回true或false的isOK()函数的调用。

由于部分创建的类可能导致的所有麻烦，我认为永远不会。

如果需要在构造过程中验证某些内容，请将构造函数设为私有并定义一个公共静态工厂方法。如果某些东西无效，该方法可以抛出。但是如果一切都检查出来了，它就调用构造函数，保证不会抛出。

构造函数抛出异常是合理的，只要它正确地清理了自己。如果您遵循RAII范式(资源获取即初始化)，那么构造函数通常会做有意义的工作;如果构造函数不能完全初始化，那么编写良好的构造函数将自行清理。

OO中通常的约定是对象方法确实有功能。

因此，作为一个推论，永远不要从构造函数/init中返回僵尸对象。

僵尸没有功能，可能缺少内部组件。只是一个空指针异常等待发生。

很多年前，我第一次在Objective C中制作僵尸。

就像所有的经验法则一样，也有一个“例外”。

一个特定的接口完全有可能有这样的契约 存在一个允许触发异常的方法“initialize”。 在调用initialize之前，实现此接口的对象可能不会正确响应除属性设置器之外的任何调用。在引导过程中，我在OO操作系统中的设备驱动程序中使用了这种方法，而且它是可行的。

一般来说，你不需要僵尸对象。在Smalltalk这样的语言中，使用变得有点冒火，但是过度使用变得也是一种糟糕的风格。be允许一个对象在原地变成另一个对象，因此不需要信封包装器(高级c++)或策略模式(GOF)。

如果你正在编写ui控件(ASPX, WinForms, WPF，…)，你应该避免在构造函数中抛出异常，因为设计器(Visual Studio)在创建控件时无法处理它们。了解你的控件生命周期(控件事件)，尽可能使用惰性初始化。

如果无法创建有效对象，则绝对应该从构造函数抛出异常。这允许您在类中提供适当的不变量。

在实践中，你可能必须非常小心。记住，在c++中，析构函数不会被调用，所以如果你在分配资源后抛出，你需要非常小心地正确处理它!

本页对c++中的情况进行了全面的讨论。