我不能说明Objective-C中的最佳实践，但在c++中，构造函数抛出异常是可以的。特别是没有其他方法可以确保在不调用isOK()方法的情况下报告构造过程中遇到的异常情况。

函数try块特性是专门为支持构造函数成员初始化失败而设计的(尽管它也可以用于常规函数)。这是修改或丰富将要抛出的异常信息的唯一方法。但由于其最初的设计目的(在构造函数中使用)，它不允许空catch()子句包含异常。

如果无法创建有效对象，则绝对应该从构造函数抛出异常。这允许您在类中提供适当的不变量。

在实践中，你可能必须非常小心。记住，在c++中，析构函数不会被调用，所以如果你在分配资源后抛出，你需要非常小心地正确处理它!

本页对c++中的情况进行了全面的讨论。

There is generally nothing to be gained by divorcing object initialization from construction. RAII is correct, a successful call to the constructor should either result in a fully initialized live object or it should fail, and ALL failures at any point in any code path should always throw an exception. You gain nothing by use of a separate init() method except additional complexity at some level. The ctor contract should be either it returns a functional valid object or it cleans up after itself and throws.

考虑一下，如果实现了单独的init方法，仍然必须调用它。它仍然有可能抛出异常，它们仍然必须被处理，而且它们实际上总是必须在构造函数之后立即被调用，除了现在你有4种可能的对象状态而不是2种(IE，已构造，初始化，未初始化，失败vs只是有效和不存在)。

In any case I've run across in 25 years of OO development cases where it seems like a separate init method would 'solve some problem' are design flaws. If you don't need an object NOW then you shouldn't be constructing it now, and if you do need it now then you need it initialized. KISS should always be the principle followed, along with the simple concept that the behavior, state, and API of any interface should reflect WHAT the object does, not HOW it does it, client code should not even be aware that the object has any kind of internal state that requires initialization, thus the init after pattern violates this principle.

请注意，如果您在初始化器中抛出异常，如果任何代码使用[[[MyObj alloc] init] autorelease]模式，那么您将最终泄漏，因为异常将跳过自动释放。

看这个问题:

在init中引发异常时如何防止泄漏?

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

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