Utilizzo efficiente del blocco try / catch?

I blocchi catch dovrebbero essere usati per scrivere la logica, ad esempio gestire il controllo del flusso, ecc.? O semplicemente per generare eccezioni? Influisce sull'efficienza o sulla manutenibilità del codice?

Quali sono gli effetti collaterali (se ce ne sono) della scrittura della logica nel blocco catch?

MODIFICARE:

Ho visto una classe SDK Java in cui hanno scritto la logica all'interno del blocco catch. Ad esempio (frammento preso dalla java.lang.Integerclasse):

        try {
            result = Integer.valueOf(nm.substring(index), radix);
            result = negative ? new Integer(-result.intValue()) : result;
        } catch (NumberFormatException e) {
            String constant = negative ? new String("-" + nm.substring(index))
                                       : nm.substring(index);
            result = Integer.valueOf(constant, radix);
        }

EDIT2 :

Stavo attraversando un tutorial in cui lo considerano un vantaggio di scrivere la logica di casi eccezionali all'interno delle eccezioni:

Le eccezioni ti consentono di scrivere il flusso principale del tuo codice e di trattare casi eccezionali altrove.

Qualche guida specifica su quando scrivere la logica nel blocco catch e quando non farlo?

L'esempio che citi è dovuto alla cattiva progettazione dell'API (non esiste un modo pulito per verificare se una stringa è un numero intero valido se non quello di provare ad analizzarla e catturare l'eccezione).

A livello tecnico, lancio e prova / cattura sono costrutti di flusso di controllo che consentono di saltare nello stack di chiamate, niente di più e niente di meno. Saltare lo stack delle chiamate in modo implicito collega il codice che non è ravvicinato nell'origine, il che è negativo per la manutenibilità . Quindi dovrebbe essere usato solo quando è necessario farlo e le alternative sono anche peggio. Il caso ampiamente accettato in cui le alternative sono peggiori è la gestione degli errori (codici di ritorno speciali che devono essere controllati e passati manualmente ogni livello dello stack di chiamate).

Se hai un caso in cui le alternative sono peggiori (e le hai davvero prese in considerazione tutte attentamente), direi che usare il tiro e provare / catturare per il flusso di controllo va bene. Il dogma non è un buon sostituto del giudizio.

Questo è qualcosa che tende a dipendere dal linguaggio e dal paradigma.

Gran parte del mio lavoro è svolto in Java (e talvolta in C ++). La tendenza è quella di utilizzare le eccezioni solo per condizioni eccezionali. Ci sono alcune domande su Stack Overflow sull'overhead delle prestazioni delle eccezioni in Java e, come puoi vedere, non è esattamente trascurabile. Vi sono anche altre preoccupazioni, come la leggibilità e la manutenibilità del codice. Se utilizzate correttamente, le eccezioni possono delegare la gestione degli errori ai componenti appropriati.

Tuttavia, in Python, l'idea che sia più facile chiedere perdono che regni l'autorizzazione. Nella comunità Python, questo è noto come EAFP , in contrasto con l' approccio "look before you jump " ( LBYL ) nei linguaggi in stile C.

Questo non è il modo migliore di pensare ai blocchi try / catch. Il modo di pensare ai blocchi try / catch è questo: si è verificato un errore, dove è il posto migliore per gestire QUESTO errore specifico. Questa potrebbe essere la riga di codice successiva, potrebbe essere di 20 livelli nella catena di chiamate. Ovunque sia, ecco dove dovrebbe essere.

Cosa fa il blocco catch dipende dall'errore e cosa puoi fare al riguardo. A volte può semplicemente essere ignorato (impossibile eliminare un file di memoria virtuale senza dati importanti), a volte verrà utilizzato per impostare un valore di ritorno delle funzioni su true o false (metodo int parse di java), a volte si esce dal programma . Tutto ciò dipende dall'errore.

La parte importante da capire è: catch block == So come affrontarlo.

I blocchi di cattura dovrebbero essere usati solo per gestire le eccezioni, nient'altro e mai e poi mai per il flusso di controllo. In qualsiasi situazione in cui si desidera utilizzare le eccezioni per gestire il flusso, è meglio verificare le condizioni preliminari.

La gestione del flusso con eccezioni è lenta e semanticamente errata.

I blocchi catch dovrebbero essere usati per scrivere la logica, ad esempio gestire il controllo del flusso, ecc.? O semplicemente per generare eccezioni? Influisce sull'efficienza o sulla manutenibilità del codice?

Innanzitutto, dimentica l'idea che "le eccezioni dovrebbero essere utilizzate per condizioni eccezionali". Smetti anche di preoccuparti dell'efficienza, finché non hai un codice che funziona in modo inaccettabile e non hai misurato per sapere dove si trova il problema.

Il codice è più facile da capire quando le azioni seguono in una sequenza semplice, senza condizionali. Le eccezioni migliorano la manutenibilità rimuovendo il controllo degli errori dal flusso normale. Non importa se l'esecuzione segue il flusso normale il 99,9% delle volte o il 50% delle volte o il 20% delle volte.

Generare un'eccezione quando una funzione non è in grado di restituire un valore, quando una procedura non è in grado di completare l'azione prevista o quando un costruttore non è in grado di produrre un oggetto utilizzabile. Ciò consente ai programmatori di assumere che una funzione restituisca sempre un risultato utilizzabile, una procedura completa sempre l'azione richiesta, un oggetto costruito è sempre in uno stato utilizzabile.

Il problema più grande che vedo con il codice di gestione delle eccezioni è che i programmatori scrivono blocchi try / catch quando non dovrebbero. Ad esempio, nella maggior parte delle applicazioni Web, se una richiesta del database genera un'eccezione, non è possibile eseguire alcuna operazione nel controller. È sufficiente una clausola di cattura generica al massimo livello. Quindi il codice del controller può tranquillamente ignorare la possibilità che il disco si sia arrestato in modo anomalo o che il database sia offline o altro.

I blocchi di cattura non devono essere utilizzati per scrivere la logica del codice. Dovrebbero essere utilizzati solo per la gestione degli errori. Un esempio è (1) ripulire qualsiasi risorsa allocata, (2) stampare un messaggio utile e (3) uscire con grazia.

È vero che le eccezioni possono essere abusate e causare gotoeffetti indesiderati . Ma ciò non li rende inutili. Se utilizzati correttamente , possono migliorare molti aspetti del codice.