Python: Est-ce une mauvaise forme de lever des exceptions dans __init__?

Est-il considéré comme une mauvaise forme de soulever des exceptions à l'intérieur __init__? Si tel est le cas, quelle est la méthode acceptée pour lancer une erreur lorsque certaines variables de classe sont initialisées comme Noneou d'un type incorrect?

Soulever des exceptions à l'intérieur __init__()est absolument parfait. Il n'y a pas d'autre bon moyen d'indiquer une condition d'erreur dans un constructeur, et il existe plusieurs centaines d'exemples dans la bibliothèque standard où la construction d'un objet peut déclencher une exception.

La classe d'erreur à élever, bien sûr, dépend de vous. ValueErrorest préférable si le constructeur a reçu un paramètre non valide.

Il est vrai que la seule manière correcte d'indiquer une erreur dans un constructeur est de lever une exception. C'est pourquoi en C ++ et dans d'autres langages orientés objet qui ont été conçus avec la sécurité des exceptions à l'esprit, le destructeur n'est pas appelé si une exception est levée dans le constructeur d'un objet (ce qui signifie que l'initialisation de l'objet est incomplète). Ce n'est souvent pas le cas dans les langages de script, tels que Python. Par exemple, le code suivant lève une AttributeError si socket.connect () échoue:

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 raison en est que le destructeur de l'objet incomplet est appelé après l'échec de la tentative de connexion, avant que l'attribut stream n'ait été initialisé. Vous ne devriez pas éviter de lancer des exceptions de la part des constructeurs, je dis simplement qu'il est difficile d'écrire du code entièrement sécurisé en Python. Certains développeurs Python évitent complètement d'utiliser des destructeurs, mais c'est un autre débat.

Je ne vois aucune raison pour que ce soit une mauvaise forme.

Au contraire, l'une des choses que les exceptions sont connues pour bien faire, par opposition au renvoi de codes d'erreur, est que les codes d'erreur ne peuvent généralement pas être retournés par les constructeurs. Donc, au moins dans des langages comme C ++, lever des exceptions est le seul moyen de signaler les erreurs.

La bibliothèque standard dit:

>>> 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'

De plus, je ne vois pas vraiment pourquoi cela devrait être considéré comme une mauvaise forme.

Je devrais penser que c'est le cas parfait pour l' ValueErrorexception intégrée .

Je suis d'accord avec tout ce qui précède.

Il n'y a vraiment pas d'autre moyen de signaler que quelque chose s'est mal passé lors de l'initialisation d'un objet autre que de lever une exception.

Dans la plupart des classes de programmes où l'état d'une classe dépend entièrement des entrées de cette classe, nous pouvons nous attendre à ce qu'une sorte de ValueError ou TypeError soit déclenchée.

Les classes avec des effets secondaires (par exemple, celles qui font du réseautage ou des graphiques) peuvent générer une erreur dans init si (par exemple) le périphérique réseau n'est pas disponible ou l'objet canevas ne peut pas être écrit. Cela me semble judicieux car vous souhaitez souvent connaître les conditions de défaillance le plus rapidement possible.

Relever des erreurs depuis init est inévitable dans certains cas, mais faire trop de travail dans init est un mauvais style. Vous devriez envisager de créer une fabrique ou une pseudo-fabrique - une méthode de classe simple qui renvoie un objet configuré.