构造函数何时抛出异常是正确的?(或者在Objective C的情况下:什么情况下init ` er才应该返回nil?)
在我看来，如果对象不完整，构造函数应该失败——因此拒绝创建对象。也就是说，构造函数应该与它的调用者有一个合同，以提供一个函数和工作对象，在哪些方法可以被有意义地调用?这合理吗?
当前回答
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/
其他回答
参见c++常见问题解答第17.2和17.4节。
一般来说，我发现如果构造函数被编写，那么它们就不会失败，那么移植和维护结果的代码就会更容易，而可能失败的代码则放在一个单独的方法中，该方法返回错误代码并使对象处于惰性状态。
我不能说明Objective-C中的最佳实践，但在c++中，构造函数抛出异常是可以的。特别是没有其他方法可以确保在不调用isOK()方法的情况下报告构造过程中遇到的异常情况。
函数try块特性是专门为支持构造函数成员初始化失败而设计的(尽管它也可以用于常规函数)。这是修改或丰富将要抛出的异常信息的唯一方法。但由于其最初的设计目的(在构造函数中使用)，它不允许空catch()子句包含异常。
如果无法创建有效对象，则绝对应该从构造函数抛出异常。这允许您在类中提供适当的不变量。
在实践中，你可能必须非常小心。记住，在c++中，析构函数不会被调用，所以如果你在分配资源后抛出，你需要非常小心地正确处理它!
本页对c++中的情况进行了全面的讨论。
当构造函数无法完成所述对象的构造时，它应该抛出异常。
例如，如果构造函数应该分配1024 KB的ram，但它没有这样做，它应该抛出一个异常，这样构造函数的调用者就知道对象还没有准备好使用，并且在某个地方存在需要修复的错误。
半初始化和半死亡的对象只会引起问题和问题，因为调用者确实没有办法知道。我宁愿让我的构造函数在出错时抛出一个错误，而不是不得不依赖编程来运行返回true或false的isOK()函数的调用。
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项，编写异常安全的代码。
