构造函数的任务是使对象进入可用状态。关于这个问题，基本上有两种观点。

一组人赞成两阶段建设。构造函数只是将对象带入一个休眠状态，在这种状态下它拒绝做任何工作。还有一个额外的函数来进行实际的初始化。

我一直不明白这种方法背后的原因。我坚决支持单阶段构造，即对象在构造后完全初始化并可用。

如果单阶段构造函数未能完全初始化对象，则应该抛出。如果对象不能初始化，则必须不允许它存在，因此构造函数必须抛出。

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/

我所见过的关于异常的最好建议是，当且仅当替代方案是未能满足post条件或保持不变时，抛出异常。

该建议将不明确的主观决策(这是个好主意吗)替换为基于设计决策(不变条件和后置条件)的技术精确问题。

Constructors are just a particular, but not special, case for that advice. So the question becomes, what invariants should a class have? Advocates of a separate initialization method, to be called after construction, are suggesting that the class has two or more operating mode, with an unready mode after construction and at least one ready mode, entered after initialization. That is an additional complication, but acceptable if the class has multiple operating modes anyway. It is hard to see how that complication is worthwhile if the class would otherwise not have operating modes.

请注意，将setup推入单独的初始化方法中并不能避免抛出异常。构造函数可能抛出的异常现在将由初始化方法抛出。如果为未初始化的对象调用类中所有有用的方法，都必须抛出异常。

还要注意，避免构造函数抛出异常的可能性是很麻烦的，在许多标准库中在许多情况下是不可能的。这是因为这些库的设计者认为从构造函数抛出异常是个好主意。特别是，任何试图获取不可共享或有限资源(例如分配内存)的操作都可能失败，而这种失败通常在OO语言和库中通过抛出异常来表示。

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

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

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

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#)

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