如果无法在构造函数中初始化对象，则抛出异常，一个例子是非法参数。

根据一般经验，应该尽可能快地抛出异常，因为当问题的根源接近发出错误信号的方法时，这会使调试变得更容易。

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

参见c++常见问题解答第17.2和17.4节。

一般来说，我发现如果构造函数被编写，那么它们就不会失败，那么移植和维护结果的代码就会更容易，而可能失败的代码则放在一个单独的方法中，该方法返回错误代码并使对象处于惰性状态。

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

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

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

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

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

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

齿顶高

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

OP的问题有一个“语言不可知论”的标签…对于所有语言/情况，这个问题不能以同样的方式安全地回答。

下面的c#示例的类层次结构抛出了类B的构造函数，跳过了对类A的IDisposeable的立即调用。在main的使用退出时进行处置，跳过类A资源的显式处置。

例如，如果类A在构造时创建了一个套接字，连接到一个网络资源，在使用块之后可能仍然是这种情况(一个相对隐藏的异常)。

class A : IDisposable
{
    public A()
    {
        Console.WriteLine("Initialize A's resources.");
    }

    public void Dispose()
    {
        Console.WriteLine("Dispose A's resources.");
    }
}

class B : A, IDisposable
{
    public B()
    {
        Console.WriteLine("Initialize B's resources.");
        throw new Exception("B construction failure: B can cleanup anything before throwing so this is not a worry.");
    }

    public new void Dispose()
    {
        Console.WriteLine("Dispose B's resources.");
        base.Dispose();
    }
}
class C : B, IDisposable
{
    public C()
    {
        Console.WriteLine("Initialize C's resources. Not called because B throws during construction. C's resources not a worry.");
    }

    public new void Dispose()
    {
        Console.WriteLine("Dispose C's resources.");
        base.Dispose();
    }
}


class Program
{
    static void Main(string[] args)
    {
        try
        {
            using (C c = new C())
            {
            }
        }
        catch
        {           
        }

        // Resource's allocated by c's "A" not explicitly disposed.
    }
}

是的，如果构造函数未能构建其内部部分之一，则它可以(通过选择)有责任抛出(并以某种语言声明)一个显式异常，这在构造函数文档中有适当的说明。

This is not the only option: It could finish the constructor and build an object, but with a method 'isCoherent()' returning false, in order to be able to signal an incoherent state (that may be preferable in certain case, in order to avoid a brutal interruption of the execution workflow due to an exception) Warning: as said by EricSchaefer in his comment, that can bring some complexity to the unit testing (a throw can increase the cyclomatic complexity of the function due to the condition that triggers it)

如果它因为调用者而失败(比如调用者提供了一个空参数，而被调用的构造函数需要一个非空参数)，构造函数无论如何都会抛出一个未检查的运行时异常。