Che errore si genera quando lo stato della classe non è valido?

Question

In una classe Python, quale tipo di errore dovrei sollevare da un metodo di istanza quando alcuni degli altri attributi della classe devono essere modificati prima di eseguire quel metodo?

Provengo da uno sfondo C# in cui vorrei usare InvalidOperationException, "l'eccezione che viene generata quando una chiamata di metodo non è valida per lo stato corrente dell'oggetto", ma non ho trovato un equivalente built-in exception in Python.

Sto sollevando ValueError ("generato quando un'operazione o una funzione incorporata riceve un argomento che ha il tipo giusto ma un valore inappropriato") quando il problema riguarda i parametri della funzione. Suppongo che questo sia tecnicamente un valore non valido per il parametro self; è questo il modo giusto per trattarlo? Ad esempio, è questo idiomatico: raise ValueError("self.foo must be set before running self.bar()")?

Answer 1

ValueError è la cosa migliore da sollevare in questo caso. Per Python, dovresti preferire l'uso di built-in exception types per creare il tuo. Dovresti creare solo nuovi tipi di eccezioni quando ti aspetti che dovrai prenderli e comportarti in modo molto diverso da come ti comporteresti quando prendi i tipi di build. In questo caso, la situazione non dovrebbe sorgere - non ti aspetti di prenderla perché potrebbe indicare un errore nell'uso della classe in questione. Per questo non vale la pena creare un nuovo tipo solo per fargli avere un altro nome - questo è ciò che è la stringa di messaggio che si passa a ValueError().

È possibile ristrutturare la classe in modo tale che uno stato non valido non sia possibile?

Answer 2

class InvalidOperationException(Exception): 
    pass 

SYS_STATE = 1 

def something_being_run(): 
    if SYS_STATE < 2: 
     raise InvalidOperationException 

Qualcosa del genere intendi? Non vedo alcun motivo per cui non dovresti eseguire un'eccezione di sottoclasse per creare i tuoi tipi di eccezione, ma potrebbe essere solo il vecchio Oracle PL/SQL Dev in me che esce ...

Answer 3

Penso che il modo pitone non lasci l'oggetto in uno stato tale in cui una chiamata al metodo non si arresti in modo anomalo nonostante si trovi in ​​uno stato errato. Questi sono i bug più difficili da trovare, dato che il punto in cui il programma finisce definitivamente non è dove si è verificato l'errore.

es.

class PseudoTuple(object): 
    """ 
The sum method of PseudoTuple will raise an AttributeError if either x or y have 
not been set 
""" 
    def setX(self, x): 
     self.x = x 

    def setY(self, y): 
     self.y = y 

    def sum(self): 
     """ 
In the documentation it should be made clear that x and y need to have been set 
for sum to work properly 
""" 
     return self.x + self.y 

class AnotherPseudoTuple(PseudoTuple): 
    """ 
For AnotherPseudoTuple sum will now raise a TypeError if x and y have not been 
properly set 
""" 
    def __init__(self, x=None, y=None): 
     self.x = x 
     self.y = y 

Quello che non si deve fare è qualcosa di simile

class BadPseudoTuple(PseudoTuple): 
    """ 
In BadPseudoTuple -1 is used to indicate an invalid state 
""" 
    def __init__(self, x=-1, y=-1): 
     self.x = x 
     self.y = y 

    def sum(self): 
     if self.x == -1 or self.y == -1: 
      raise SomeException("BadPseudoTuple in invalid state") 
     else: 
      return self.x + self.y 

Credo che questo avviene sotto il motto divinatorio di:

E 'più facile chiedere perdono che è di ottenere il permesso

Se lo stato eccezionale è qualcosa che può essere si prevede che accada durante il normale corso dell'esecuzione piuttosto che essere un errore dell'utente abusando della classe, quindi sembra ragionevole che tu debba creare la tua eccezione. StopIteration e iterators ne sono un esempio.

Answer 4

Penso che si dovrebbe aumentare un ValueError quando il problema è con i parametri di funzione, come si sta facendo, e un AttributeError quando il problema è con un attributo che deve essere impostato.

Inoltre, è possibile creare sottoclasse dello AttributeError per creare un'eccezione più specifica, ma non è necessario. L'eccezione AttributeError con il tuo messaggio di errore è abbastanza chiara.

Answer 5

ValueError va bene per me, ma penso che AssertionError sia più appropriato. Fondamentalmente, viola l'asserzione fatta dal progettista dell'API.

Answer 6

Io trovo il RuntimeError il più appropriato di tutte le eccezioni built-in per segnalare lo stato non valido.

Vedi questo esempio di come viene utilizzato in CPython:

Python 2.7.10 (default, Jul 13 2015, 12:05:58) 
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin 
Type "help", "copyright", "credits" or "license" for more information. 
>>> from threading import Thread 
>>> Thread().join() 
Traceback (most recent call last): 
    File "<stdin>", line 1, in <module> 
    File "/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 938, in join 
    raise RuntimeError("cannot join thread before it is started") 
RuntimeError: cannot join thread before it is started 

E 'importante notare che anche l'attuazione CPython sé non è coerente circa l'uso di specifici tipi di eccezione tra le librerie. A volte viene usato lo ValueError, ma a mio avviso la sua descrizione dalla documentazione di Python mostra che il suo uso è riservato ad altre situazioni. RuntimeError è un'eccezione più generale e dovrebbe essere utilizzata quando un pezzo di codice non può comportarsi correttamente se viene fornito un input appropriato, che è in qualche modo simile alla situazione in cui un oggetto si trova in uno stato non valido.