È una clausola try-catch-finally appropriata per il codice di produzione?

Nella domanda / risposta collegata a, la soluzione corretta consiste nel correggere il fatto che il codice di annullamento dell'iscrizione è chiamato più del codice di sottoscrizione. Se non c'è il tempo per risolverlo, ignorare quella specifica eccezione potrebbe essere una soluzione alternativa utile a breve termine. Ma sappiamo tutti cosa significa questo nel codice di produzione.

Nel caso generale, non esiste una risposta chiara "taglia unica". Esistono argomenti validi a favore e contro le eccezioni in generale, ma la verità è che alcuni linguaggi e librerie li usano così da poterli abituare a trattare efficacemente con loro.

A volte un'eccezione è relativamente innocua e dovrebbe innescare un comportamento diverso da un rethrow. Ad esempio, se l'input non è un numero valido (ad es. java.lang.NumberFormatException ) e non possono essere memorizzati in un campo numerico. Forse c'è un modo per indicarlo sull'interfaccia utente e riprovare l'operazione di input.

A volte un'eccezione è molto più seria (es. std :: bad_alloc ) e il tuo programma potrebbe voler prendilo, esegui una pulizia minima e ripeti il tiro per uccidersi. Nel caso di un std::bad_alloc , sarebbe ovviamente una cattiva idea allocare più memoria durante la pulizia.

Ciò significa che devi veramente valutare ogni situazione. Pensa "cosa ha causato questa eccezione?" e "qual è il risultato realistico durante questo gestore di eccezioni?" Potrebbe significare qualcosa dalla convalida dell'input che cattura qualcosa di sbagliato, a qualcosa di così grave che non c'è modo di recuperare altro che scrivere una traccia di stack o un numero di riga nel log e uscire.

Si noti come il blocco Try-Catch nella risposta collegata non faccia effettivamente nulla. Non sta facendo nulla per mitigare l'errore, nemmeno per averlo segnalato.

Ecco perché potrebbe fallire in qualsiasi momento. Se ciò che sta causando l'errore si ripresenta, e tu provi a usare l'oggetto all'interno del blocco try, potrebbe causare un errore più avanti nel codice, in punti apparentemente casuali.

I blocchi Try-Catch-Finally sono perfettamente accettabili (e davvero quasi obbligatori) nel codice di produzione, in quanto offrono un mezzo per ricadere nelle lingue abilitate all'eccezione. Sarebbe difficile trovare un codice java di produzione che non abbia blocchi try-catch di qualche tipo.

Per entrare in dettaglio, le eccezioni sono fondamentalmente un modo per dire alla funzione chiamante che qualcosa è andato storto. È possibile farlo restituendo un valore null, ma in questo modo è necessario eseguire tutti i passaggi rimanenti. Se utilizzi un metodo di 150 righe molto pesante per le risorse (esegui query su un database, effettua chiamate a un'API esterna) e sai subito che qualcosa non va (non hai fornito un nome utente, hai dimenticato di impostare un obbligatorio campo) è possibile ignorare tutti quei passaggi aggiuntivi e solo sollevare un'eccezione, uscendo immediatamente dalla funzione. Permette anche di bypassare le funzioni intermedie. Se stai utilizzando una classe inferiore che genera un'eccezione e non sai cosa fare con essa, la passi semplicemente alla classe superiore, dove quell'eccezione potrebbe avere più senso.