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

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

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

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

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

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

Eric Lippert说有四种例外。

Fatal exceptions are not your fault, you cannot prevent them, and you cannot sensibly clean up from them. Boneheaded exceptions are your own darn fault, you could have prevented them and therefore they are bugs in your code. Vexing exceptions are the result of unfortunate design decisions. Vexing exceptions are thrown in a completely non-exceptional circumstance, and therefore must be caught and handled all the time. And finally, exogenous exceptions appear to be somewhat like vexing exceptions except that they are not the result of unfortunate design choices. Rather, they are the result of untidy external realities impinging upon your beautiful, crisp program logic.

构造函数本身不应该抛出致命异常，但它执行的代码可能会导致致命异常。像“内存不足”这样的事情不是您可以控制的，但是如果它发生在构造函数中，嘿，它就发生了。

愚蠢的异常永远不应该出现在任何代码中，所以它们应该被清除。

构造函数不应该抛出恼人的异常(例如Int32.Parse())，因为它们没有非异常情况。

最后，应该避免外生异常，但如果在构造函数中执行的某些操作依赖于外部环境(如网络或文件系统)，则抛出异常是合适的。

参考链接:https://blogs.msdn.microsoft.com/ericlippert/2008/09/10/vexing-exceptions/

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

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

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

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

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

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

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

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

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

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