Quando dovrei creare una sottoclasse di un'eccezione in Python?

Question

Quando dovrei creare una sottoclasse di un'eccezione in Python?

#1 da (8 voti)

10

Nel mio codice ci sono circa sette posti in cui sollevo un'eccezione. Tutte queste eccezioni sono trattate allo stesso modo: stampa un errore per registrare il file, riporta lo stato del software su predefinito ed esci.

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

La mia argomentazione è che al momento ridurrà solo il nostro codice e, dal momento che non sappiamo se gestiremo le eccezioni in modo diverso, dovremmo lasciare il codice terso e, se e quando verrà il momento, allora e solo allora dovremmo sottotipo.

Mi piacerebbe sentire qualsiasi argomento per ogni caso.

python object-oriented-design exceptions

posta Ezra 08.03.2015 - 16:36

fonte

1 risposta

Leggi altre domande sui tag python object-oriented-design exceptions

DDD: è corretto per un aggregato radice contenere un riferimento a un altro aggregato radice? Quali sono i modi possibili per evitare i duplicati quando non è possibile aggiungere un indice univoco

score 8 · Answer 1

Hai ragione

L'argomento della tua parte è già stato menzionato da Robert Harvey: non aggiungere il codice che non ti serve in questo momento, specialmente perché è facile aggiungerlo in un secondo momento.

Anche il tuo revisore ha ragione

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

Restituire un generico Exception() non è molto utile per il chiamante: mentre la descrizione dell'eccezione indica a un umano cosa sta succedendo, il trattamento di eccezioni in modo diverso a livello di programmazione può essere impossibile. Lo sviluppatore che utilizza il tuo codice potrebbe essere riluttante a modificare i tipi di eccezioni , incluso il timore (giustificato o meno) di rompere qualcosa.

Tieni presente che l'aggiunta di eccezioni personalizzate al momento non è poi così difficile :
```
class MyCustomException(Exception):
    pass
```
è tutto ciò di cui hai bisogno. Sono solo due righe di codice (dato che potresti non aver nemmeno bisogno di creare un file separato se inserisci 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 di indovinare che il prezzo è fuori portata (o forse non lo è? Forse ci sono casi in cui il prezzo può essere negativo, come gli sconti?)
- Nel primo pezzo di codice, un'anteprima del tipo fornisce un'indicazione immediata dell'errore. Sembra che esista un insieme di valori consentiti per un prezzo e il valore corrente non rientra in questo set.

così?

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