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

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

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

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

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

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

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

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

齿顶高

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

Throwing an exception during construction is a great way to make your code way more complex. Things that would seem simple suddenly become hard. For example, let's say you have a stack. How do you pop the stack and return the top value? Well, if the objects in the stack can throw in their constructors (constructing the temporary to return to the caller), you can't guarantee that you won't lose data (decrement stack pointer, construct return value using copy constructor of value in stack, which throws, and now have a stack that just lost an item)! This is why std::stack::pop does not return a value, and you have to call std::stack::top.

这个问题在这里有很好的描述，检查第10项，编写异常安全的代码。

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.
    }
}

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/

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