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

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

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

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

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

对我来说，这是一个有点哲学的设计决策。

拥有实例是非常好的，只要它们存在就有效，从ctor时间开始。对于许多重要的情况，如果无法进行内存/资源分配，则可能需要从ctor抛出异常。

其他一些方法是init()方法，它本身存在一些问题。其中之一是确保init()实际被调用。

一个变体使用惰性方法在第一次调用访问器/突变器时自动调用init()，但这要求任何潜在的调用者都必须担心对象是否有效。(而不是“它存在，因此它是有效的哲学”)。

我也看到过处理这个问题的各种设计模式。例如，可以通过ctor创建初始对象，但必须调用init()来获得包含的、初始化的具有访问器/突变器的对象。

每种方法都有其利弊;我已经成功地使用了所有这些方法。如果不是在创建对象的那一刻就创建现成的对象，那么我建议使用大量的断言或异常，以确保用户在init()之前不会进行交互。

齿顶高

我是从c++程序员的角度写的。我还假设您正确地使用了RAII习惯用法来处理抛出异常时释放的资源。

我不确定是否有答案可以完全与语言无关。有些语言处理异常和内存管理的方式不同。

I've worked before under coding standards requiring exceptions never be used and only error codes on initializers, because developers had been burned by the language poorly handling exceptions. Languages without garbage collection will handle heap and stack very differently, which may matter for non RAII objects. It is important though that a team decide to be consistent so they know by default if they need to call initializers after constructors. All methods (including constructors) should also be well documented as to what exceptions they can throw, so callers know how to handle them.

我通常支持单阶段构造，因为很容易忘记初始化对象，但也有很多例外。

Your language support for exceptions isn't very good. You have a pressing design reason to still use new and delete Your initialization is processor intensive and should run async to the thread that created the object. You are creating a DLL that may be throwing exceptions outside it's interface to an application using a different language. In this case it may not be so much an issue of not throwing exceptions, but making sure they are caught before the public interface. (You can catch C++ exceptions in C#, but there are hoops to jump through.) Static constructors (C#)

我不能说明Objective-C中的最佳实践，但在c++中，构造函数抛出异常是可以的。特别是没有其他方法可以确保在不调用isOK()方法的情况下报告构造过程中遇到的异常情况。

函数try块特性是专门为支持构造函数成员初始化失败而设计的(尽管它也可以用于常规函数)。这是修改或丰富将要抛出的异常信息的唯一方法。但由于其最初的设计目的(在构造函数中使用)，它不允许空catch()子句包含异常。

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

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

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

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

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

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

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