Python: это плохой тон - вызывать исключения в __init__?

Считается ли дурным тоном создавать исключения внутри __init__? Если да, то каков принятый метод выдачи ошибки, когда определенные переменные класса инициализируются как Noneнеправильного типа или имеют неправильный тип?

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

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

Верно, что единственный правильный способ указать ошибку в конструкторе - это вызвать исключение. Вот почему в C ++ и других объектно-ориентированных языках, которые были разработаны с учетом безопасности исключений, деструктор не вызывается, если в конструкторе объекта возникает исключение (что означает, что инициализация объекта не завершена). В языках сценариев, таких как Python, этого часто не происходит. Например, следующий код вызывает ошибку AttributeError в случае сбоя socket.connect ():

class NetworkInterface:
    def __init__(self, address)
        self.socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        self.socket.connect(address)
        self.stream = self.socket.makefile()

    def __del__(self)
        self.stream.close()
        self.socket.close()

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

Я не вижу причин, по которым это должно быть плохим тоном.

Напротив, одна из вещей, которые, как известно, работают хорошо, в отличие от возврата кодов ошибок, заключается в том, что коды ошибок обычно не могут быть возвращены конструкторами. Так что, по крайней мере, в таких языках, как C ++, создание исключений - единственный способ сигнализировать об ошибках.

Стандартная библиотека говорит:

>>> f = file("notexisting.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory: 'notexisting.txt'

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

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

Я согласен со всем вышесказанным.

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

В большинстве программных классов, где состояние класса полностью зависит от входных данных для этого класса, мы можем ожидать возникновения какой-либо ValueError или TypeError.

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

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