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

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)

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

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

严格地从Java的角度来说，任何时候初始化使用非法值的构造函数时，它都应该抛出异常。这样它就不会被构造成一个糟糕的状态。

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

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

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

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

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

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

我所见过的关于异常的最好建议是，当且仅当替代方案是未能满足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语言和库中通过抛出异常来表示。