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

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

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

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

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

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

据我所知，没有人能提出一个相当明显的解决方案，同时体现了一阶段和两阶段结构的优点。

注意:这个答案假设是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方法之一。

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

我真正这么做的唯一一次是在某个地方出现了安全问题，这意味着对象不应该，而不是不能，被创建。

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.