Sto lavorando al libro "Head First Python" (è la mia lingua da imparare quest'anno) e sono arrivato a una sezione in cui discutono di due tecniche di codice:
Verifica prima e Gestione delle eccezioni.

Ecco un esempio del codice Python:

# Checking First
for eachLine in open("../../data/sketch.txt"):
    if eachLine.find(":") != -1:
        (role, lineSpoken) = eachLine.split(":",1)
        print("role=%(role)s lineSpoken=%(lineSpoken)s" % locals())

# Exception handling        
for eachLine in open("../../data/sketch.txt"):
    try:
        (role, lineSpoken) = eachLine.split(":",1)
        print("role=%(role)s lineSpoken=%(lineSpoken)s" % locals())
    except:
        pass

Il primo esempio affronta direttamente un problema nella .splitfunzione. Il secondo consente al gestore delle eccezioni di gestirlo (e ignora il problema).

Discutono nel libro di usare la gestione delle eccezioni invece di controllare prima. L'argomento è che il codice di eccezione rileverà tutti gli errori, in cui il primo controllo prenderà solo le cose a cui pensi (e ti perdi i casi d'angolo). Mi è stato insegnato a controllare prima, quindi il mio istinto iniziale era quello di farlo, ma la loro idea è interessante. Non avevo mai pensato di usare la gestione delle eccezioni per gestire i casi.

Quale delle due è generalmente considerata la migliore pratica?

In .NET, è pratica comune evitare l'uso eccessivo di Eccezioni. Un argomento è rappresentato dalle prestazioni: in .NET, generare un'eccezione è costoso dal punto di vista computazionale.

Un altro motivo per evitare il loro uso eccessivo è che può essere molto difficile leggere il codice che si basa troppo su di essi. Il blog di Joel Spolsky fa un buon lavoro nel descrivere il problema.

Al centro dell'argomento c'è la seguente citazione:

Il ragionamento è che considero le eccezioni non migliori di "goto", considerate dannose sin dagli anni '60, in quanto creano un brusco salto da un punto di codice a un altro. In realtà sono significativamente peggiori di quelli di goto:

1. Sono invisibili nel codice sorgente . Osservando un blocco di codice, incluse le funzioni che possono o meno generare eccezioni, non c'è modo di vedere quali eccezioni potrebbero essere generate e da dove. Ciò significa che anche un'attenta ispezione del codice non rivela potenziali bug.

2. Creano troppi punti di uscita possibili per una funzione. Per scrivere il codice corretto, devi davvero pensare a ogni possibile percorso del codice attraverso la tua funzione. Ogni volta che chiami una funzione che può sollevare un'eccezione e non rilevarla sul posto, crei opportunità per bug a sorpresa causati da funzioni che si sono interrotte bruscamente, lasciando i dati in uno stato incoerente o altri percorsi di codice che non hai Pensa a.

Personalmente, lancio eccezioni quando il mio codice non può fare ciò per cui è stato contratto. Tendo a usare try / catch quando sto per trattare qualcosa al di fuori del mio limite di processo, ad esempio una chiamata SOAP, una chiamata al database, un file IO o una chiamata di sistema. Altrimenti, provo a programmare in modo difensivo. Non è una regola dura e veloce, ma è una pratica generale.

Scott Hanselman scrive anche delle eccezioni in .NET qui . In questo articolo descrive diverse regole pratiche relative alle eccezioni. Il mio preferito?

Non dovresti fare eccezioni per le cose che accadono continuamente. Quindi sarebbero "ordinari".

In Python in particolare, di solito è considerata una buona pratica catturare l'eccezione. Tende a essere chiamato Più facile da chiedere perdono che autorizzazione (EAFP), rispetto a Look Before You Leap (LBYL). Ci sono casi in cui LBYL ti darà bug sottili in alcuni casi.

Tuttavia, fai attenzione alle affermazioni nudeexcept: e overbroad tranne le dichiarazioni, poiché entrambi possono anche mascherare i bug - qualcosa del genere sarebbe meglio:

for eachLine in open("../../data/sketch.txt"):
    try:
        role, lineSpoken = eachLine.split(":",1)
    except ValueError:
        pass
    else:
        print("role=%(role)s lineSpoken=%(lineSpoken)s" % locals())

Un approccio pragmatico

Dovresti essere difensivo ma fino a un certo punto. È necessario scrivere la gestione delle eccezioni, ma fino a un certo punto. Userò la programmazione web come esempio perché è qui che vivo.

1. Supponiamo che tutto l'input dell'utente sia errato e scrivi in ​​modo difensivo solo al punto di verifica del tipo di dati, controlli dei modelli e iniezione dannosa. La programmazione difensiva dovrebbe essere qualcosa che può accadere potenzialmente molto spesso e che non puoi controllare.
2. Scrivi la gestione delle eccezioni per i servizi di rete che a volte potrebbero non funzionare e gestisci con garbo il feedback degli utenti. La programmazione delle eccezioni dovrebbe essere usata per cose collegate in rete che possono fallire di tanto in tanto ma sono generalmente solide E devi far funzionare il tuo programma.
3. Non preoccuparti di scrivere in modo difensivo nella tua applicazione dopo aver convalidato i dati di input. È una perdita di tempo e gonfia la tua app. Lascialo esplodere perché è qualcosa di molto raro che non vale la pena maneggiare o significa che devi guardare più attentamente i passaggi 1 e 2.
4. Non scrivere mai la gestione delle eccezioni nel codice principale che non dipende da un dispositivo in rete. Farlo è una cattiva programmazione e costoso per le prestazioni. Ad esempio, scrivere un try-catch in caso di array fuori limite in un loop significa che non è stato programmato correttamente il loop in primo luogo.
5. Lascia che tutto sia gestito dalla registrazione degli errori centrale che rileva le eccezioni in un unico posto dopo aver seguito le procedure sopra. Non è possibile rilevare tutti i casi limite poiché potrebbe essere infinito, è sufficiente scrivere codice che gestisca le operazioni previste. Ecco perché usi la gestione centralizzata degli errori come ultima risorsa.
6. TDD è bello perché in un certo senso ti sta cercando di catturare senza gonfiare, il che significa darti una certa sicurezza del normale funzionamento.
7. I punti bonus consistono nell'utilizzare uno strumento di copertura del codice, ad esempio Istanbul è una buona opzione per il nodo, poiché questo ti mostra dove non stai testando.
8. L'avvertenza di tutto ciò sono le eccezioni favorevoli agli sviluppatori . Ad esempio, una lingua verrebbe lanciata se si usasse la sintassi errata e spiegasse il perché. Lo stesso vale per le librerie di utilità da cui dipende la maggior parte del codice.

Ciò deriva dall'esperienza lavorativa in grandi scenari di gruppo.

Un'analogia

Immagina di indossare sempre una tuta spaziale all'interno della ISS. Sarebbe difficile andare in bagno o mangiare, per niente. Sarebbe super voluminoso all'interno del modulo spaziale muoversi. Farebbe schifo. Scrivere un sacco di prove nel tuo codice è un po 'così. Devi avere un punto in cui dici, ehi, ho assicurato che la ISS e i miei astronauti all'interno siano OK, quindi non è pratico indossare una tuta spaziale per ogni scenario che potrebbe accadere.

L'argomento principale del libro è che la versione di eccezione del codice è migliore perché catturerà tutto ciò che potresti aver trascurato se provassi a scrivere il tuo controllo degli errori.

Penso che questa affermazione sia vera solo in circostanze molto specifiche - in cui non ti importa se l'output è corretto.

Non c'è dubbio che sollevare eccezioni è una pratica solida e sicura. Dovresti farlo ogni volta che ritieni che ci sia qualcosa nello stato attuale del programma che tu (come sviluppatore) non puoi o non vuoi affrontare.

Il tuo esempio, tuttavia, riguarda la cattura di eccezioni. Se si cattura un'eccezione, si sta non proteggersi da scenari si potrebbe avere trascurato. Stai facendo esattamente il contrario: supponi di non aver trascurato nessuno scenario che potrebbe aver causato questo tipo di eccezione, e quindi sei sicuro che sia corretto catturarlo (e quindi impedirgli di causare l'uscita dal programma, come qualsiasi eccezione non rilevata).

Utilizzando l'approccio delle eccezioni, se vedi ValueErrorun'eccezione, salti una riga. Usando il tradizionale approccio senza eccezioni, conti il ​​numero di valori restituiti da splite se è inferiore a 2, salti una riga. Dovresti sentirti più sicuro con l'approccio delle eccezioni, dal momento che potresti aver dimenticato alcune altre situazioni di "errore" nel tuo tradizionale controllo degli errori e le except ValueErroravresti prese per te?

Questo dipende dalla natura del tuo programma.

Se stai scrivendo, ad esempio, un browser Web o un lettore video, un problema con gli input non dovrebbe causare un arresto anomalo con un'eccezione non rilevata. È molto meglio produrre qualcosa di sensibilmente remoto (anche se, a rigore, errato) piuttosto che smettere.

Se stai scrivendo un'applicazione in cui la correttezza è importante (come software aziendali o di ingegneria), questo sarebbe un approccio terribile. Se ti sei dimenticato di uno scenario che genera ValueError, la cosa peggiore che puoi fare è ignorare silenziosamente questo scenario sconosciuto e semplicemente saltare la linea. Ecco come i bug molto sottili e costosi finiscono nel software.

Potresti pensare che l'unico modo in cui puoi vedere ValueErrorin questo codice, è se splitrestituito solo un valore (anziché due). Ma cosa succede se la tua printaffermazione in seguito inizia a utilizzare un'espressione che si solleva ValueErrorin alcune condizioni? Questo ti farà saltare alcune linee non perché mancano :, ma perché printfalliscono su di esse. Questo è un esempio di un bug sottile a cui mi riferivo prima: non noteresti nulla, perdi solo alcune righe.

La mia raccomandazione è di evitare di catturare (ma non sollevare!) Eccezioni nel codice in cui produrre output errati è peggio che uscire. L'unica volta in cui rilevo un'eccezione in tale codice è quando ho un'espressione davvero banale, quindi posso facilmente ragionare su ciò che può causare ciascuno dei possibili tipi di eccezione.

Per quanto riguarda l'impatto sulle prestazioni dell'uso delle eccezioni, è banale (in Python) a meno che non si incontrino frequentemente eccezioni.

Se si utilizzano eccezioni per gestire le condizioni che si verificano abitualmente, in alcuni casi è possibile che si paghino costi di prestazioni enormi. Ad esempio, supponiamo di eseguire qualche comando in remoto. È possibile verificare che il testo del comando superi almeno la convalida minima (ad es. Sintassi). Oppure potresti aspettare che venga sollevata un'eccezione (che si verifica solo dopo che il server remoto analizza il tuo comando e trova un problema con esso). Ovviamente, il primo è ordini di grandezza più veloci. Un altro semplice esempio: è possibile verificare se un numero è zero ~ 10 volte più veloce rispetto al tentativo di eseguire la divisione e quindi rilevare l'eccezione ZeroDivisionError.

Queste considerazioni sono importanti solo se si inviano frequentemente stringhe di comando non valide ai server remoti o si ricevono argomenti a valore zero che si utilizzano per la divisione.

Nota: suppongo che useresti al except ValueErrorposto del giusto except; come altri hanno sottolineato, e come dice il libro stesso in poche pagine, non si dovrebbe mai usare nudo except.

Un'altra nota: l'approccio corretto senza eccezioni è quello di contare il numero di valori restituiti split, piuttosto che cercare :. Quest'ultimo è troppo lento, poiché ripete il lavoro svolto splite potrebbe quasi raddoppiare i tempi di esecuzione.

Come regola generale, se si conosce che un'istruzione potrebbe generare un risultato non valido, verificarlo e gestirlo. Usa le eccezioni per cose che non ti aspetti; roba "eccezionale". Rende il codice più chiaro in senso contrattuale ("non dovrebbe essere nullo" come esempio).

Usa ciò che mai funziona bene in ..

• il linguaggio di programmazione scelto in termini di leggibilità ed efficienza del codice
• la tua squadra e il set di convenzioni di codice concordate

Sia la gestione delle eccezioni che la programmazione difensiva sono modi diversi di esprimere lo stesso intento.

TBH, non importa se usi il try/exceptmeccanico o un ifcontrollo delle dichiarazioni. Normalmente vedi sia EAFP che LBYL nella maggior parte delle linee di base di Python, con EAFP leggermente più comune. A volte EAFP è molto più leggibile / idiomatico, ma in questo caso particolare penso che vada bene in entrambi i modi.

Però...

Starei attento a usare il tuo riferimento attuale. Un paio di problemi evidenti con il loro codice:

1. Il descrittore di file è trapelato. Le versioni moderne di CPython (uno specifico interprete Python) lo chiuderanno effettivamente, dal momento che è un oggetto anonimo che rientra nell'ambito del solo ciclo (gc lo annulla dopo il ciclo). Tuttavia, altri interpreti non hanno questa garanzia. Possono fuoriuscire completamente il descrittore. Quasi sempre vuoi usare il withlinguaggio quando leggi file in Python: ci sono pochissime eccezioni. Questo non è uno di questi.
2. La gestione delle eccezioni di Pokemon è disapprovata mentre maschera gli errori (vale a dire exceptun'istruzione nuda che non rileva un'eccezione specifica)
3. Nit: non hai bisogno di parentesi per disimballare la tupla. Posso solo farerole, lineSpoken = eachLine.split(":",1)

Ivc ha una buona risposta su questo e EAFP, ma perde anche il descrittore.

La versione LBYL non è necessariamente performante come la versione EAFP, quindi dire che generare eccezioni è "costoso in termini di prestazioni" è categoricamente falso. Dipende molto dal tipo di stringhe che stai elaborando:

In [33]: def lbyl(lines):
    ...:     for line in lines:
    ...:         if line.find(":") != -1:
    ...:             # Nuke the parens, do tuple unpacking like an idiomatic Python dev.
    ...:             role, lineSpoken = line.split(":",1)
    ...:             # no print, since output is obnoxiously long with %timeit
    ...:

In [34]: def eafp(lines):
    ...:     for line in lines:
    ...:         try:
    ...:             # Nuke the parens, do tuple unpacking like an idiomatic Python dev.
    ...:             role, lineSpoken = eachLine.split(":",1)
    ...:             # no print, since output is obnoxiously long with %timeit
    ...:         except:
    ...:             pass
    ...:

In [35]: lines = ["abc:def", "onetwothree", "xyz:hij"]

In [36]: %timeit lbyl(lines)
100000 loops, best of 3: 1.96 µs per loop

In [37]: %timeit eafp(lines)
100000 loops, best of 3: 4.02 µs per loop

In [38]: lines = ["a"*100000 + ":" + "b", "onetwothree", "abconetwothree"*100]

In [39]: %timeit lbyl(lines)
10000 loops, best of 3: 119 µs per loop

In [40]: %timeit eafp(lines)
100000 loops, best of 3: 4.2 µs per loop

Fondamentalmente la gestione delle eccezioni dovrebbe essere più appropriata per le lingue OOP.

Il secondo punto è la prestazione, perché non è necessario eseguire eachLine.findper ogni riga.

Penso che la programmazione difensiva danneggi le prestazioni. Dovresti anche cogliere solo le eccezioni che gestirai, lasciare che il runtime gestisca l'eccezione che non sai come gestire.