Quando dovrei sottoclassare un'eccezione in Python?

Nel mio codice ci sono circa sette posti in cui sollevo un'eccezione. Tutte queste eccezioni sono trattate allo stesso modo: stampare un errore nel file di registro, ripristinare lo stato del software predefinito ed uscire.

Durante la revisione del codice il mio ingegnere senior, che apprezzo molto, ha detto che dovrei sottoclassare tutte queste eccezioni. La sua tesi è che in futuro potremmo voler gestire le eccezioni in modo diverso e sarà più facile.

La mia argomentazione è che attualmente ingombrerà solo il nostro codice e, poiché non sappiamo se gestiremo mai diversamente le eccezioni, dovremmo lasciare il codice conciso e, se e quando verrà il momento, allora e solo allora dovremmo sottotipare .

Vorrei sentire qualsiasi argomento per ogni caso.

python object-oriented-design exceptions

— Ezra
fonte

YAGNI ... Non ti serve ora e puoi sempre aggiungerlo in seguito senza troppe difficoltà.

— Robert Harvey,

Hai qualche esempio? Stai solo generando Exception, ad esempio, o errori incorporati più specifici?

— jonrsharpe,

solo sollevando un'eccezione ("descrizione specifica")

— Ezra

@Ezra almeno, dovresti vedere se esiste un'eccezione incorporata più adatta (vedi docs.python.org/2/library/exceptions.html ).

— jonrsharpe

Hai ragione

L'argomento per la tua parte è già citato da Robert Harvey: non aggiungere codice che non ti serve in questo momento, soprattutto perché è facile aggiungerlo in seguito.

Anche il tuo recensore ha ragione

D'altra parte, anche il punto del recensore è comprensibile:

Restituire un generico Exception()non è molto utile per il chiamante: mentre la descrizione dell'eccezione indica a un essere umano cosa sta succedendo, trattare le eccezioni in modo diverso a livello di programmazione può essere impossibile. Lo sviluppatore che utilizza il codice può essere riluttante a modificare i tipi di eccezioni , anche per paura (giustificata o meno) di infrangere qualcosa.

Tieni presente che l' aggiunta di eccezioni personalizzate in questo momento non è poi così difficile :
```
class MyCustomException(Exception):
    pass
```
é tutto quello di cui hai bisogno. Sono solo due righe di codice (dato che potrebbe non essere nemmeno necessario creare un file separato se si inseriscono eccezioni personalizzate in un file).
Il codice stesso sembra migliore, più leggibile.
```
if price < self.PriceMinValue:
    raise OutOfRangeException("The price is inferior to zero.")
```
sembra leggermente più leggibile rispetto a:
```
if price < self.PriceMinValue:
    raise Exception("The price is inferior to zero.")
```
a causa dell'indicazione del tipo di eccezione:
- Nel secondo pezzo di codice, ho bisogno di leggere la descrizione e indovinare che il prezzo è fuori range (o forse no? Forse ci sono casi in cui il prezzo può essere negativo, come gli sconti?)
- Nel primo pezzo di codice, uno sguardo al tipo fornisce un'indicazione immediata dell'errore. Sembra che ci sia un set di valori consentiti per un prezzo e il valore corrente è al di fuori di questo set.

Così?

Così:

Entrambi gli approcci sono validi. Se non subclassi le eccezioni quando non hai bisogno di tipi personalizzati, hai ragione. Quando esegui la sottoclasse delle eccezioni perché non costa nulla per farlo e può essere utile in seguito, hai ragione.
Sii coerente con la tua squadra. Se il tuo team utilizza ampiamente le eccezioni personalizzate, utilizzale.

— Arseni Mourzenko
fonte

Ma c'è una via di mezzo: raise ValueError('The price is less than zero'). Questo è più specifico della base Exception, ma senza complicazioni.

— jonrsharpe,

+1 per la semplice dichiarazione "essere coerenti", con una squadra se ne hai una, con te stesso se non lo fai.

— Styne666,