构造函数什么时候抛出异常是正确的？

Question

构造函数什么时候抛出异常是正确的？ （或者在 Objective C 的情况下：init'er 什么时候返回 nil 是正确的？）

在我看来，如果对象不完整，构造函数应该失败——从而拒绝创建对象。 即，构造函数应该与其调用者签订合同，以提供一个功能和工作对象，哪些方法可以被有意义地调用？ 这合理吗？

Answer 1

构造函数的工作是使对象进入可用状态。 关于这一点，基本上有两种思想流派。

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

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

如果一级构造函数未能完全初始化对象，则它们应该抛出。 如果对象不能被初始化，它一定不允许存在，所以构造函数必须抛出。

Answer 2

Eric Lippert 说有 4 种例外。

• 致命异常不是您的错，您无法阻止它们，也无法明智地清除它们。
• 愚蠢的异常是您自己的该死的错误，您可以阻止它们，因此它们是您代码中的错误。
• 令人烦恼的异常是不幸的设计决策的结果。 恼人的异常是在完全非异常的情况下抛出的，因此必须一直被捕获和处理。
• 最后，外生异常似乎有点像令人烦恼的异常，只是它们不是不幸的设计选择的结果。 相反，它们是不整洁的外部现实影响您漂亮、清晰的程序逻辑的结果。

您的构造函数不应该自己抛出致命异常，但它执行的代码可能会导致致命异常。 诸如“内存不足”之类的事情不是您可以控制的，但是如果它发生在构造函数中，嘿，它就会发生。

愚蠢的异常永远不应该出现在您的任何代码中，所以它们是正确的。

令人Int32.Parse()异常（例如Int32.Parse() ）不应由构造函数抛出，因为它们没有非异常情况。

最后，应避免外生异常，但如果您在构造函数中执行某些依赖于外部环境（如网络或文件系统）的操作，则抛出异常是合适的。

参考链接： https : //blogs.msdn.microsoft.com/ericlippert/2008/09/10/vexing-exceptions/

Answer 3

将对象初始化与构造分离通常没有任何好处。 RAII 是正确的，对构造函数的成功调用要么导致完全初始化的活动对象，要么失败，并且任何代码路径中任何点的所有失败都应始终引发异常。 使用单独的 init() 方法除了在某种程度上增加复杂性外，您一无所获。 ctor 合约应该要么返回一个功能有效的对象，要么在它自己之后清理并抛出。

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

无论如何，我在 25 年的面向对象开发案例中遇到过，似乎一个单独的 init 方法可以“解决一些问题”是设计缺陷。 如果你现在不需要一个对象，那么你现在不应该构造它，如果你现在需要它，那么你需要初始化它。 KISS 应该始终是遵循的原则，以及任何接口的行为、状态和 API 应该反映对象做什么而不是如何做的简单概念，客户端代码甚至不应该知道对象有任何种类需要初始化的内部状态，因此 init after 模式违反了这一原则。

Answer 4

由于部分创建的类可能会导致所有麻烦，我会说永远不会。

如果您需要在构造过程中验证某些内容，请将构造函数设为私有并定义公共静态工厂方法。 如果某些内容无效，该方法可能会抛出。 但是如果一切都检查出来，它会调用构造函数，保证不会抛出。

Answer 5

构造函数在无法完成所述对象的构造时应该抛出异常。

例如，如果构造函数应该分配 1024 KB 的 ram，而它没有这样做，它应该抛出异常，这样构造函数的调用者就知道该对象尚未准备好使用，并且存在错误需要修复的地方。

半初始化和半死的对象只会导致问题和问题，因为调用者真的没有办法知道。 我宁愿让我的构造函数在出现问题时抛出错误，也不愿依靠编程来运行对返回 true 或 false 的 isOK() 函数的调用。

Answer 6

据我所知，没有人提出一个相当明显的解决方案，它体现了单级和两级构造的优点。

注意：此答案假设使用 C#，但这些原则适用于大多数语言。

首先，两者的好处：

一级

单阶段构建通过防止对象以无效状态存在而使我们受益，从而防止各种错误的状态管理以及随之而来的所有错误。 然而，它让我们中的一些人感到奇怪，因为我们不希望我们的构造函数抛出异常，有时这就是当初始化参数无效时我们需要做的事情。

public class Person
{
    public string Name { get; }
    public DateTime DateOfBirth { get; }

    public Person(string name, DateTime dateOfBirth)
    {
        if (string.IsNullOrWhitespace(name))
        {
            throw new ArgumentException(nameof(name));
        }

        if (dateOfBirth > DateTime.UtcNow) // side note: bad use of DateTime.UtcNow
        {
            throw new ArgumentOutOfRangeException(nameof(dateOfBirth));
        }

        this.Name = name;
        this.DateOfBirth = dateOfBirth;
    }
}

两阶段通过验证方法

两阶段构造允许我们在构造函数之外执行验证，从而使我们受益，因此不需要在构造函数中抛出异常。 然而，它给我们留下了“无效”的实例，这意味着我们必须跟踪和管理实例的状态，或者我们在堆分配后立即将其丢弃。 这就引出了一个问题：为什么我们要在一个我们甚至没有最终使用的对象上执行堆分配，从而进行内存收集？

public class Person
{
    public string Name { get; }
    public DateTime DateOfBirth { get; }

    public Person(string name, DateTime dateOfBirth)
    {
        this.Name = name;
        this.DateOfBirth = dateOfBirth;
    }

    public void Validate()
    {
        if (string.IsNullOrWhitespace(Name))
        {
            throw new ArgumentException(nameof(Name));
        }

        if (DateOfBirth > DateTime.UtcNow) // side note: bad use of DateTime.UtcNow
        {
            throw new ArgumentOutOfRangeException(nameof(DateOfBirth));
        }
    }
}

通过私有构造函数的单阶段

那么我们如何才能将异常排除在我们的构造函数之外，并防止我们对将立即丢弃的对象执行堆分配呢？ 这是非常基本的：我们将构造函数设为私有并通过静态方法创建实例，该静态方法指定执行实例化，因此仅在验证之后进行堆分配。

public class Person
{
    public string Name { get; }
    public DateTime DateOfBirth { get; }

    private Person(string name, DateTime dateOfBirth)
    {
        this.Name = name;
        this.DateOfBirth = dateOfBirth;
    }

    public static Person Create(
        string name,
        DateTime dateOfBirth)
    {
        if (string.IsNullOrWhitespace(Name))
        {
            throw new ArgumentException(nameof(name));
        }

        if (dateOfBirth > DateTime.UtcNow) // side note: bad use of DateTime.UtcNow
        {
            throw new ArgumentOutOfRangeException(nameof(DateOfBirth));
        }

        return new Person(name, dateOfBirth);
    }
}

通过私有构造函数的异步单阶段

除了前面提到的验证和堆分配预防的好处之外，以前的方法为我们提供了另一个很好的优势：异步支持。 这在处理多阶段身份验证时会派上用场，例如当您需要在使用 API 之前检索不记名令牌时。 这样，您最终不会得到一个无效的“注销”API 客户端，相反，如果您在尝试执行请求时收到授权错误，您可以简单地重新创建 API 客户端。

public class RestApiClient
{
    public RestApiClient(HttpClient httpClient)
    {
        this.httpClient = new httpClient;
    }

    public async Task<RestApiClient> Create(string username, string password)
    {
        if (username == null)
        {
            throw new ArgumentNullException(nameof(username));
        }

        if (password == null)
        {
            throw new ArgumentNullException(nameof(password));
        }

        var basicAuthBytes = Encoding.ASCII.GetBytes($"{username}:{password}");
        var basicAuthValue = Convert.ToBase64String(basicAuthBytes);

        var authenticationHttpClient = new HttpClient
        {
            BaseUri = new Uri("https://auth.example.io"),
            DefaultRequestHeaders = {
                Authentication = new AuthenticationHeaderValue("Basic", basicAuthValue)
            }
        };

        using (authenticationHttpClient)
        {
            var response = await httpClient.GetAsync("login");
            var content = response.Content.ReadAsStringAsync();
            var authToken = content;
            var restApiHttpClient = new HttpClient
            {
                BaseUri = new Uri("https://api.example.io"), // notice this differs from the auth uri
                DefaultRequestHeaders = {
                    Authentication = new AuthenticationHeaderValue("Bearer", authToken)
                }
            };

            return new RestApiClient(restApiHttpClient);
        }
    }
}

根据我的经验，这种方法的缺点很少。

通常，使用这种方法意味着您不能再将类用作 DTO，因为反序列化为没有公共默认构造函数的对象充其量是很困难的。 但是，如果您将对象用作 DTO，则您不应该真正验证对象本身，而是在尝试使用对象时使对象上的值无效，因为从技术上讲，这些值并不是“无效”的到 DTO。

这也意味着当您需要允许 IOC 容器创建对象时，您最终将创建工厂方法或类，否则容器将不知道如何实例化对象。 然而，在很多情况下，工厂方法最终成为Create方法本身之一。

Answer 7

它总是很狡猾，特别是当你在构造函数中分配资源时； 根据您的语言，不会调用析构函数，因此您需要手动清理。 这取决于对象的生命周期在您的语言中何时开始。

我真正这样做的唯一一次是当某处存在安全问题时，这意味着不应创建对象，而不是不能创建对象。

Answer 8

构造函数抛出异常是合理的，只要它正确地清理了自己。 如果您遵循RAII范式（资源获取即初始化），那么构造函数做有意义的工作是很常见的； 如果不能完全初始化，编写良好的构造函数将在其自身之后进行清理。

Answer 9

如果您正在编写 UI 控件（ASPX、WinForms、WPF...），您应该避免在构造函数中抛出异常，因为设计器 (Visual Studio) 在创建控件时无法处理它们。 了解您的控制生命周期（控制事件）并尽可能使用延迟初始化。

Answer 10

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

看到这个问题：

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

Answer 11

请参阅 C++ FAQ 部分17.2和17.4 。

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

Answer 12

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

在实践中，您可能必须非常小心。 请记住，在 C++ 中，不会调用析构函数，因此如果在分配资源后抛出异常，则需要非常小心地正确处理！

本页对 C++ 中的情况进行了彻底的讨论。

Answer 13

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

作为一般的经验法则，应该总是尽快抛出异常，因为当问题的根源更接近于发出错误信号的方法时，它会使调试更容易。

Answer 14

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

我以前在编码标准下工作过，要求从不使用异常，并且只在初始化程序上使用错误代码，因为开发人员已经被语言处理异常的能力所困扰。 没有垃圾收集的语言将非常不同地处理堆和堆栈，这对于非 RAII 对象可能很重要。 重要的是，团队决定保持一致，以便他们知道默认情况下是否需要在构造函数之后调用初始化器。 所有方法（包括构造函数）也应该详细记录它们可以抛出哪些异常，以便调用者知道如何处理它们。

我通常赞成单阶段构造，因为很容易忘记初始化对象，但也有很多例外。

• 您对异常的语言支持不是很好。
• 你有一个紧迫的设计理由仍然使用new和delete
• 您的初始化是处理器密集型的，应该与创建对象的线程异步运行。
• 您正在创建一个 DLL，该 DLL 可能会在它与使用不同语言的应用程序的接口之外抛出异常。 在这种情况下，可能不是不抛出异常的问题，而是确保它们在公共接口之前被捕获。 （您可以在 C# 中捕获 C++ 异常，但需要跳过一些障碍。）
• 静态构造函数 (C#)

Answer 15

OP 的问题有一个“与语言无关”的标签……对于所有语言/情况，不能以相同的方式安全地回答这个问题。

以下 C# 示例的类层次结构抛出类 B 的构造函数，在退出 main 的using时跳过对类 A 的IDisposeable.Dispose的立即调用，跳过对类 A 资源的显式处置。

例如，如果类 A 在构造时创建了一个Socket ，连接到网络资源，那么在using块之后可能仍然是这种情况（一个相对隐藏的异常）。

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

Answer 16

是的，如果构造函数未能构建其内部部分之一，则可以选择 - 它有责任抛出（并在某些语言中声明） 显式异常，在构造函数文档中适当注明。

这不是唯一的选择：它可以完成构造函数并构建一个对象，但使用方法“isCoherent()”返回 false，以便能够发出不连贯状态的信号（在某些情况下可能更可取，以便以避免由于异常导致执行工作流的粗暴中断）
警告：正如 EricSchaefer 在他的评论中所说，这会给单元测试带来一些复杂性（由于触发它的条件，抛出会增加函数的圈复杂度）

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

Answer 17

在构造过程中抛出异常是使代码更复杂的好方法。 原本看似简单的事情突然变得困难起来。 例如，假设您有一个堆栈。 你如何弹出堆栈并返回顶部值？ 好吧，如果堆栈中的对象可以在其构造函数中抛出（构造临时返回给调用者），则不能保证不会丢失数据（递减堆栈指针，使用value in的复制构造函数构造返回值堆栈，它抛出，现在有一个堆栈只是失去了一个项目）！ 这就是 std::stack::pop 不返回值的原因，您必须调用 std::stack::top 。

这个问题在这里得到了很好的描述，检查条款 10，编写异常安全的代码。

Answer 18

OO 中的通常约定是对象方法确实起作用。

因此，作为推论，永远不要从构造函数/初始化程序中返回僵尸对象。

僵尸无法正常工作，可能缺少内部组件。 只是一个等待发生的空指针异常。

许多年前，我第一次在 Objective C 中制作了僵尸。

像所有的经验法则一样，有一个“例外”。

完全有可能一个特定的接口可能有一个约定，说明存在一个允许引发异常的方法“初始化”。 在调用 initialize 之前，实现此接口的对象可能无法正确响应除属性设置器之外的任何调用。 我在启动过程中将其用于 OO 操作系统中的设备驱动程序，并且它是可行的。

一般来说，你不想要僵尸对象。 在像 Smalltalk 这样的语言中，使用become 的东西会变得有点混乱，但过度使用become也是一种糟糕的风格。 成为让一个对象就地变成另一个对象，所以不需要信封包装器（高级 C++）或策略模式（GOF）。

Answer 19

我无法解决 Objective-C 中的最佳实践，但在 C++ 中，构造函数抛出异常是没问题的。 特别是因为没有其他方法可以确保在不调用 isOK() 方法的情况下报告构造时遇到的异常情况。

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

Answer 20

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

该建议将基于您应该已经做出的设计决策（不变和后置条件）的技术性、精确问题替换为不明确的主观决策（这是个好主意）。

构造函数只是该建议的一个特殊情况，但并不特殊。 那么问题就变成了，一个类应该有哪些不变量？ 一个单独的初始化方法中，主张施工后的帮助，将表明类具有两个或多个操作模式中，与结构和至少一个准备模式后的未就绪模式，在初始化之后进入。 这是一个额外的复杂性，但如果该类有多种操作模式，则可以接受。 如果班级没有操作模式，很难看出这种复杂性有多大价值。

请注意，将设置推送到单独的初始化方法中并不能避免引发异常。 您的构造函数可能抛出的异常现在将由初始化方法抛出。 如果为未初始化的对象调用这些方法，则类的所有有用方法都必须抛出异常。

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

Answer 21

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

Answer 22

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

拥有只要存在就有效的实例非常好，从 ctor 时间开始。 对于许多非平凡的情况，如果无法进行内存/资源分配，这可能需要从构造函数抛出异常。

其他一些方法是 init() 方法，它有自己的一些问题。 其中之一是确保 init() 实际被调用。

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

我也看到了各种提议的设计模式来处理这个问题。 例如能够通过 ctor 创建初始对象，但必须调用 init() 来获取包含访问器/修改器的包含的初始化对象。

每种方法都有其起伏； 我已经成功地使用了所有这些。 如果您不从创建即用型对象的那一刻起就创建它们，那么我建议使用大量断言或异常来确保用户不会在 init() 之前进行交互。

附录

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

Answer 23

我只是在学习Objective C，所以我无法从经验中说出来，但我确实在苹果的文档中读过这篇文章。

http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/chapter_3_section_6.html

它不仅会告诉您如何处理您提出的问题，而且还可以很好地解释它。

Answer 24

对所有对象创建使用工厂或工厂方法，您可以避免无效对象，而不会从构造函数抛出异常。 如果能够创建，则创建方法应该返回请求的对象，否则返回 null。 您在处理类用户的构造错误时失去了一点灵活性，因为返回 null 并没有告诉您对象创建中出了什么问题。 但它也避免了每次请求一个对象时增加多个异常处理程序的复杂性，以及捕获不应该处理的异常的风险。

Answer 25

ctors不应该做任何“聪明”的事情，所以无论如何都不需要抛出异常。 如果要执行更复杂的对象设置，请使用Init（）或Setup（）方法。