try - excepciones en python
Python: ¿es mala forma levantar excepciones dentro de__init__? (7)
Creo que es el caso perfecto para la excepción ValueError .
¿Se considera mala forma levantar excepciones dentro de __init_? Si es así, ¿cuál es el método aceptado para arrojar un error cuando ciertas variables de clase se inicializan como None o de un tipo incorrecto?
En algunos casos, evitar los errores de init es inevitable, pero hacer demasiado trabajo en init es un mal estilo. Debería considerar hacer una fábrica o una pseudo fábrica: un método de clase simple que devuelve un objeto configurado.
Es cierto que la única forma correcta de indicar un error en un constructor es presentar una excepción. Es por eso que en C ++ y en otros lenguajes orientados a objetos que han sido diseñados teniendo en cuenta la seguridad de excepciones, no se llama al destructor si se lanza una excepción en el constructor de un objeto (lo que significa que la inicialización del objeto está incompleta). Este no suele ser el caso en los lenguajes de scripting, como Python. Por ejemplo, el siguiente código arroja un AttributeError si socket.connect () falla:
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()
La razón es que se llama al destructor del objeto incompleto después de que el intento de conexión ha fallado, antes de que el atributo de la secuencia se haya inicializado. No deberías evitar arrojar excepciones de los constructores, solo digo que es difícil escribir un código completamente seguro en Python. Algunos desarrolladores de Python evitan usar destructores por completo, pero eso es una cuestión de otro debate.
Estoy de acuerdo con todo lo anterior.
Realmente no hay otra manera de señalar que algo salió mal en la inicialización de un objeto que no sea generar una excepción.
En la mayoría de las clases de programas donde el estado de una clase depende totalmente de las entradas a esa clase, podemos esperar que se genere algún tipo de ValueError o TypeError.
Las clases con efectos secundarios (p. Ej., Una que hace networking o gráficos) pueden generar un error en init si (por ejemplo) el dispositivo de red no está disponible o no se puede escribir en el objeto canvas. Esto me parece sensato porque a menudo quiere saber sobre las condiciones de falla lo antes posible.
La biblioteca estándar dice:
>>> 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''
Además, realmente no veo ningún motivo por el que deba considerarse mala forma.
No veo ninguna razón por la que debería ser mala forma.
Por el contrario, una de las excepciones de las cosas que se sabe que funcionan bien, a diferencia de los códigos de error de retorno, es que los códigos de error generalmente no pueden ser devueltos por los constructores. Entonces, al menos en idiomas como C ++, elevar excepciones es la única forma de señalar errores.
Plantear excepciones dentro de __init__() es absolutamente __init__() . No hay otra manera de indicar una condición de error dentro de un constructor, y hay muchos cientos de ejemplos en la biblioteca estándar donde crear un objeto puede generar una excepción.
La clase de error para plantear, por supuesto, depende de usted. ValueError es mejor si el constructor recibió un parámetro no válido.