Когда конструктор может генерировать исключение?

Из-за всех проблем, которые может вызвать частично созданный класс, я бы сказал никогда.

Если вам нужно что-то проверить во время строительства, сделайте конструктор закрытым и определите общедоступный статический фабричный метод. Метод может бросить, если что-то не так. Но если все проходит проверку, он вызывает конструктор, который гарантированно не сработает.

Это всегда довольно хитроумно, особенно если вы распределяете ресурсы внутри конструктора; в зависимости от вашего языка деструктор не будет вызван, поэтому вам нужно очистить его вручную. Это зависит от того, как на вашем языке начинается жизнь объекта.

Единственный раз, когда я действительно это сделал, - это когда где-то возникла проблема с безопасностью, которая означает, что объект не должен или не может быть создан.

Задача конструктора - привести объект в пригодное для использования состояние. По этому поводу существуют две основные точки зрения.

Одна группа выступает за двухэтапное строительство. Конструктор просто переводит объект в спящее состояние, в котором он отказывается выполнять какую-либо работу. Есть дополнительная функция, которая выполняет фактическую инициализацию.

Я никогда не понимал причины этого подхода. Я твердо нахожусь в группе, которая поддерживает одноэтапное строительство, когда объект полностью инициализируется и может использоваться после построения.

Одноэтапные конструкторы должны выбрасывать, если им не удается полностью инициализировать объект. Если объект не может быть инициализирован, он не должен существовать, поэтому конструктор должен выбросить.

См. Разделы часто задаваемых вопросов по C++ 17,2 и 17,4.

В общем, я обнаружил, что код, который легче переносить и поддерживать результаты, если конструкторы написаны так, чтобы они не выходили из строя, а код, который может дать сбой, помещается в отдельный метод, который возвращает код ошибки и оставляет объект в инертном состоянии. .

Конструктор разумно генерировать исключение, если он правильно очищает себя. Если вы следуете парадигме RAII (получение ресурсов - это инициализация), тогда является довольно часто конструктор выполняет значимую работу; хорошо написанный конструктор, в свою очередь, очистит после себя, если он не может быть полностью инициализирован.

Да, если конструктору не удается построить одну из своих внутренних частей, он может - по своему усмотрению - выдавать (и на определенном языке объявлять) явное исключение, должным образом отмеченное в документации конструктора.

Это не единственный вариант: он может завершить конструктор и построить объект, но с методом isCoherent (), возвращающим false, чтобы иметь возможность сигнализировать о некогерентном состоянии (что может быть предпочтительнее в определенных случаях, чтобы чтобы избежать резкого прерывания рабочего процесса выполнения из-за исключения)
Предупреждение: как сказал Эрик Шефер в своем комментарии, это может внести некоторую сложность в модульное тестирование (бросок может увеличить цикломатическая сложность функции из-за условия, которое его запускает)

Если это не удается из-за вызывающей стороны (например, нулевой аргумент, предоставленный вызывающей стороной, где вызываемый конструктор ожидает ненулевой аргумент), конструктор все равно выдаст непроверенное исключение времени выполнения.

Создание исключения во время построения - отличный способ сделать ваш код более сложным. Вещи, которые казались простыми, внезапно становятся трудными. Например, допустим, у вас есть стек. Как вы открываете стек и возвращаете верхнее значение? Что ж, если объекты в стеке могут вставлять свои конструкторы (создание временного объекта для возврата вызывающему), вы не можете гарантировать, что не потеряете данные (уменьшите указатель стека, создайте возвращаемое значение, используя конструктор копирования значения в стек, который кидает, и теперь есть стек, который только что потерял предмет)! Вот почему std :: stack :: pop не возвращает значение, и вам нужно вызвать std :: stack :: top.

Эта проблема хорошо описана здесь, проверьте пункт 10, напишите код, безопасный для исключений.

Вы обязательно должны выбросить исключение из конструктора, если вы не можете создать допустимый объект. Это позволяет вам предоставить правильные инварианты в вашем классе.

На практике вам, возможно, придется быть очень осторожным. Помните, что в C++ деструктор не будет вызываться, поэтому, если вы выбрасываете после выделения ресурсов, вам нужно позаботиться о том, чтобы обработать это правильно!

Эта страница подробно обсуждает ситуацию в C++.

Если говорить строго с точки зрения Java, каждый раз, когда вы инициализируете конструктор с недопустимыми значениями, он должен вызывать исключение. Таким образом, он не будет построен в плохом состоянии.

Для меня это несколько философское дизайнерское решение.

Очень приятно иметь экземпляры, которые действительны, пока они существуют, начиная с момента создания. Для многих нетривиальных случаев это может потребовать выброса исключений из ctor, если невозможно выделить память / ресурсы.

Некоторые другие подходы - это метод init (), который имеет свои собственные проблемы. Один из них - обеспечение фактического вызова init ().

В одном из вариантов используется ленивый подход для автоматического вызова init () при первом вызове метода доступа / мутатора, но для этого требуется, чтобы любой потенциальный вызывающий объект беспокоился о том, что объект действителен. (В отличие от «он существует, следовательно, это действительная философия»).

Я видел различные предлагаемые шаблоны проектирования для решения этой проблемы. Например, возможность создать начальный объект через ctor, но при этом необходимо вызвать init (), чтобы получить доступ к содержащемуся, инициализированному объекту с акцесорами / мутаторами.

У каждого подхода есть свои плюсы и минусы; Я успешно все это использовал. Если вы не делаете готовые к использованию объекты с момента их создания, я рекомендую большую дозу утверждений или исключений, чтобы убедиться, что пользователи не взаимодействуют до init ().

Дополнение

Я писал с точки зрения программистов на C++. Я также предполагаю, что вы правильно используете идиому RAII для обработки ресурсов, высвобождаемых при возникновении исключений.

Обычный контракт в объектно-ориентированном стиле заключается в том, что методы объекта действительно работают.

Итак, как заключение, никогда не возвращать зомби-объект из конструктора / init.

Зомби не работает, и, возможно, в нем отсутствуют внутренние компоненты. Просто ожидание исключения с нулевым указателем.

Я впервые создал зомби в Objective C много лет назад.

Как и во всех эмпирических правилах, есть «исключения».

Вполне возможно, что специфический интерфейс может иметь контракт, в котором говорится, что существует метод "инициализации", позволяющий запускать исключение. Что объект, реализующий этот интерфейс, может некорректно реагировать на какие-либо вызовы, кроме установщиков свойств, до тех пор, пока не будет вызвана инициализация. Я использовал это для драйверов устройств в операционной системе OO во время процесса загрузки, и это было работоспособно.

В общем, вам не нужны зомби-объекты. В таких языках, как Smalltalk с становиться, все становится немного странно, но чрезмерное использование становиться - тоже плохой стиль. Become позволяет объекту превращаться в другой объект на месте, поэтому нет необходимости в оболочке-оболочке (Advanced C++) или шаблоне стратегии (GOF).

Эрик Липперт говорит есть 4 вида исключений.

• Фатальные исключения - это не ваша вина, вы не можете их предотвратить и не можете разумно избавиться от них.
• Тупоголовые исключения - это ваша собственная чертова ошибка, вы могли бы предотвратить их, и поэтому они являются ошибками в вашем коде.
• Досадные исключения являются результатом неудачных дизайнерских решений. Досадные исключения выбрасываются в совершенно неисключительных обстоятельствах, и поэтому их необходимо постоянно вылавливать и обрабатывать.
• И, наконец, экзогенные исключения выглядят чем-то вроде неприятных исключений, за исключением того, что они не являются результатом неудачного выбора дизайна. Скорее, они являются результатом неопрятной внешней реальности, посягающей на вашу красивую и четкую логику программы.

Ваш конструктор никогда не должен сам по себе генерировать фатальное исключение, но код, который он выполняет, может вызвать фатальное исключение. Что-то вроде «нехватки памяти» нельзя контролировать, но если это происходит в конструкторе, это случается.

Тупоголовые исключения никогда не должны возникать ни в одном коде, поэтому они прямо сейчас.

Досадные исключения (например, Int32.Parse()) не должны создаваться конструкторами, потому что они не имеют неисключительных обстоятельств.

Наконец, следует избегать экзогенных исключений, но если вы делаете что-то в своем конструкторе, зависящее от внешних обстоятельств (например, сети или файловой системы), было бы целесообразно создать исключение.

Ссылка для ссылки: https://blogs.msdn.microsoft.com/ericlippert/2008/09/10/vexing-exceptions/

Я не могу обратиться к лучшим практикам в Objective-C, но в C++ конструктор может генерировать исключение. Тем более, что нет другого способа гарантировать, что исключительное условие, обнаруженное при построении, будет сообщено без обращения к методу isOK ().

Функция блока try была разработана специально для поддержки сбоев при поэлементной инициализации конструктора (хотя она также может использоваться для обычных функций). Это единственный способ изменить или дополнить генерируемую информацию об исключении. Но из-за своей первоначальной цели разработки (использование в конструкторах) он не позволяет исключить исключение с помощью пустого предложения catch ().

Конструктор должен генерировать исключение, когда он не может завершить построение указанного объекта.

Например, если конструктор должен выделить 1024 КБ оперативной памяти, а он не может этого сделать, он должен выдать исключение, таким образом вызывающий конструктор знает, что объект не готов к использованию и есть ошибка. где-то, что нужно исправить.

Объекты, которые наполовину инициализированы и наполовину мертвы, просто вызывают проблемы и проблемы, так как вызывающий действительно не имеет возможности узнать об этом. Я бы предпочел, чтобы мой конструктор выдавал ошибку, когда что-то пойдет не так, вместо того, чтобы полагаться на программирование для запуска вызова функции isOK (), которая возвращает true или false.

Вызывайте исключение, если вы не можете инициализировать объект в конструкторе, например, недопустимые аргументы.

Как правило, исключение всегда должно создаваться как можно скорее, поскольку это облегчает отладку, когда источник проблемы находится ближе к методу, сигнализирующему о том, что что-то не так.

в общем ничего не даст, отделив инициализацию объекта от построения. RAII правильный, успешный вызов конструктора должен привести либо к полностью инициализированному живому объекту, либо к сбою, а сбои ВСЕ в любой точке любого пути кода всегда должны вызывать исключение. Вы ничего не получите, используя отдельный метод init (), кроме дополнительной сложности на каком-то уровне. Контракт ctor должен либо возвращать функциональный действительный объект, либо очищаться после себя и выбрасывать.

Учтите, что если вы реализуете отдельный метод инициализации, вам придется вызывать его Все еще. У него по-прежнему будет возможность генерировать исключения, их все равно нужно обрабатывать, и они практически всегда должны вызываться сразу после конструктора, за исключением того, что теперь у вас есть 4 возможных состояния объекта вместо 2 (IE, сконструирован, инициализирован, неинициализирован, и не удалось против просто действительного и несуществующего).

В любом случае, за 25 лет разработки в объектно-ориентированном стиле я встречал случаи, когда казалось, что отдельный метод инициализации «решит некоторую проблему» - это недостатки дизайна. Если вам не нужен объект СЕЙЧАС, вам не следует создавать его сейчас, а если он вам нужен сейчас, вам нужно его инициализировать. KISS всегда должен следовать принципу, наряду с простой концепцией, согласно которой поведение, состояние и API любого интерфейса должны отражать ЧТО делает объект, а не КАК он это делает, клиентский код не должен даже знать, что объект имеет какой-либо вид. внутреннего состояния, требующего инициализации, поэтому шаблон init after нарушает этот принцип.

Используя фабрики или фабричные методы для создания всех объектов, вы можете избежать недопустимых объектов, не создавая исключений из конструкторов. Метод создания должен возвращать запрошенный объект, если он может его создать, или null, если нет. Вы теряете немного гибкости при обработке ошибок конструкции у пользователя класса, потому что возвращение null не говорит вам, что пошло не так при создании объекта. Но он также позволяет избежать добавления сложности из нескольких обработчиков исключений каждый раз, когда вы запрашиваете объект, и риска перехвата исключений, которые вы не должны обрабатывать.

Если вы пишете элементы управления UI (ASPX, WinForms, WPF, ...), вам следует избегать создания исключений в конструкторе, потому что дизайнер (Visual Studio) не может их обработать при создании элементов управления. Знайте свой жизненный цикл элемента управления (события управления) и по возможности используйте отложенную инициализацию.

Обратите внимание, что если вы создадите исключение в инициализаторе, вы закончите утечку, если какой-либо код использует шаблон [[[MyObj alloc] init] autorelease], поскольку исключение пропустит автоматический выпуск.

См. Этот вопрос:

Как предотвратить утечку при возникновении исключения в init?

Насколько я могу судить, никто не предлагает достаточно очевидного решения, в котором воплощены лучшие черты как одноэтапного, так и двухэтапного строительства.

Примечание: Этот ответ предполагает 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.

Лучший совет, который я видел по поводу исключений, - это генерировать исключение тогда и только тогда, когда альтернативой является невыполнение условия публикации или сохранение инварианта.

Этот совет заменяет нечеткое субъективное решение (является ли это отличная идея) техническим, точным вопросом, основанным на проектных решениях (инвариантных и пост-условиях), которые вы уже должны были принять.

Конструкторы - это всего лишь частный, но не особый случай этого совета. Возникает вопрос: какие инварианты должны быть у класса? Сторонники отдельного метода инициализации, который должен вызываться после построения, предполагают, что класс имеет два или более рабочий режим, с режимом не готов после построения и по крайней мере одним режимом готовы, введенным после инициализации. Это дополнительная сложность, но она допустима, если в классе и так есть несколько режимов работы. Трудно понять, насколько оправдано это усложнение, если в противном случае у класса не было бы рабочих режимов.

Обратите внимание, что включение настройки в отдельный метод инициализации не позволяет избежать возникновения исключений. Исключения, которые мог создать ваш конструктор, теперь будут выдаваться методом инициализации. Все полезные методы вашего класса должны будут генерировать исключения, если они вызываются для неинициализированного объекта.

Также обратите внимание, что избежать возможности создания исключений вашим конструктором проблематично, и во многих случаях невозможно во многих стандартных библиотеках. Это связано с тем, что разработчики этих библиотек считают, что выбрасывать исключения из конструкторов - это хорошая идея. В частности, любая операция, которая пытается получить не разделяемый или конечный ресурс (например, выделение памяти), может завершиться ошибкой, и этот сбой обычно указывается в объектно-ориентированных языках и библиотеках с помощью исключения.

Я не уверен, что любой ответ может быть полностью независимым от языка. Некоторые языки по-разному обрабатывают исключения и управление памятью.

Раньше я работал в соответствии со стандартами кодирования, требующими, чтобы исключения никогда не использовались, а только коды ошибок в инициализаторах, потому что разработчики были обижены языком, плохо обрабатывающим исключения. Языки без сборки мусора будут обрабатывать кучу и стек по-разному, что может иметь значение для объектов, отличных от RAII. Однако важно, чтобы команда решила быть последовательной, чтобы по умолчанию знать, нужно ли вызывать инициализаторы после конструкторов. Все методы (включая конструкторы) также должны быть хорошо документированы в отношении того, какие исключения они могут генерировать, чтобы вызывающие абоненты знали, как их обрабатывать.

Я вообще сторонник одноэтапной конструкции, так как легко забыть инициализировать объект, но есть много исключений из этого.

• У вас не очень хорошая языковая поддержка исключений.
• У вас есть веская причина по дизайну, чтобы по-прежнему использовать new и delete.
• Инициализация требует интенсивного использования процессора и должна выполняться асинхронно с потоком, создавшим объект.
• Вы создаете DLL, которая может генерировать исключения за пределами своего интерфейса для приложения, использующего другой язык. В этом случае проблема может заключаться не столько в том, чтобы не генерировать исключения, сколько в том, чтобы убедиться, что они перехватываются перед общедоступным интерфейсом. (Вы можете поймать исключения C++ в C#, но есть обручи, через которые нужно прыгнуть.)
• Статические конструкторы (C#)

Вопрос OP имеет тег «языковой независимости» ... на этот вопрос нельзя безопасно ответить одинаково для всех языков / ситуаций.

В следующем примере C# иерархия классов вызывает конструктор класса B, пропуская немедленный вызов IDisposeable.Dispose класса A при выходе из using основного, пропуская явное удаление ресурсов класса 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.
    }
}