Errori comuni nella gestione delle eccezioni

Un'eccezione è un'interruzione del normale flusso di esecuzione di un programma Java (o qualsiasi altro). Questa violazione può verificarsi a causa di una violazione dell'accesso alla memoria, di una divisione per zero, di un problema di inizializzazione, dell'esecuzione di un'istruzione non valida o di qualsiasi altro errore fatale. Java è in grado di gestire con garbo tutti questi scenari indesiderati, ma quando si tratta di utilizzare queste funzionalità Java da parte degli sviluppatori, possono sorgere diversi problemi. In questo articolo non discuterò di come funziona la gestione delle eccezioni in Java. Presumo che il lettore abbia già familiarità con la gerarchia delle eccezioni, le eccezioni controllate , le eccezioni non controllate e le eccezioni di runtime . Qui discuteremo degli errori più comuni che dovresti evitare.

Stakeholder nelle eccezioni

Ogni volta che il thread di esecuzione viene interrotto, le informazioni su di esso devono essere restituite all'esecutore del programma. Questo thread può iniziare dallo schermo, da un'attività batch o in qualsiasi altro modo. Tutti questi trigger attendono qualche tipo di violazione nel flusso per trasmettere un messaggio di un determinato formato. Un trigger basato su schermata può farci sapere delicatamente che ci sono alcuni problemi tecnici e dovremmo contattare l'assistenza per aiuto e consigli. I processi batch o i programmi Java autonomi potrebbero aspettarsi che la segnalazione degli errori venga visualizzata sotto forma di una sorta di registro completamente incomprensibile per l'utente finale. Ma gli uomini d’affari hanno bisogno di ricevere messaggi in una lingua che comprendono. La temuta NullPointerException nella mente degli utenti è molto fastidiosa. A volte questi errori sono una conseguenza dell'uso errato del programma, ma a volte sono problemi che richiedono una correzione. Il secondo importante stakeholder è la persona che dovrà affrontare i problemi sollevati dalle eccezioni. Questa persona non può osservare l'effettiva esecuzione del programma quando si verifica l'eccezione. Si baserà su due cose: in primo luogo, le informazioni fornite dall'utente che sta riscontrando il problema e, in secondo luogo, una sorta di registro generato quando si verifica un'eccezione. Inoltre, la persona che analizzerà il problema non è la stessa persona che ha scritto il programma, e quindi lo sviluppatore del programma deve fornire informazioni sufficienti per l'analisi. L'unico modo di comunicazione tra lo sviluppatore del programma e il suo debugger è un registro. Inoltre, a volte per motivi di sicurezza, il registro di registro a volte potrebbe non contenere tutti i dettagli effettivi dell'esecuzione del programma quando si è verificata l'eccezione. Diamo un'occhiata ai possibili errori nella gestione delle eccezioni. Alcuni sembrano piuttosto stupidi, ma ci sono persone. che non prestano loro attenzione finché questi errori non portano a problemi.

Blocco eccezioni vuoto

Questo è uno degli errori più indesiderati nella gestione delle eccezioni. In questo caso l'eccezione viene semplicemente ignorata. La soluzione non contiene altro che una riga di commento per lasciare l'eccezione. try{ }catch(SQLException sqe){ // do nothing } In alcuni rari casi, come nel blocco finale quando il database viene chiuso, potrebbero essere generate eccezioni. In questo caso possono essere ignorati. try{ }catch(SQLException sqe){ ... ... }finally{ try{ conn.close(); }catch(Exception e){ //leave it. } }

Generalizzazione errata del messaggio di eccezione

Questo punto è soggettivo. Dopo aver rilevato l'eccezione, puoi segnalarla all'utente finale sotto forma di un messaggio amichevole. È del tutto possibile che i dettagli del messaggio originale vadano persi quando i messaggi originali vengono convertiti in un messaggio generale. Il messaggio dovrebbe trasmettere le informazioni corrette all'utente finale in modo che, quando contatta il team di supporto, l'utente debba solo accedere al registro appropriato per fornire le informazioni. try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new Exception("File Processing Failed",ioe); } In un'applicazione multilivello, ogni livello rileva le eccezioni e genera un nuovo tipo di eccezione. A volte è assolutamente necessario lanciare un'eccezione di un certo tipo: - Data Access Layer -> crea una DataAccessException - Business Implementation Layer -> crea una BusinessException - Application Service Layer -> crea una ApplicationServiceException Tutto sembra logico, non è vero? Qui potremmo dover scegliere tra ApplicationServiceException e BusinessException poiché entrambi possono rappresentare le stesse informazioni. Una di queste conversioni di eccezioni sembra non necessaria.

Distruggere la classe StackTrace

Durante il processo di trasformazione di un'eccezione in un nuovo tipo speciale, l'analisi dello stack potrebbe scomparire, rendendo un incubo il rintracciamento della causa effettiva dell'eccezione. Nel codice seguente puoi vedere come viene lanciata una nuova eccezione senza ricevere alcuna informazione dall'eccezione originale. try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new MyException("Problem in data reading."); }

Sovrascrivere il motivo dell'eccezione

Ogni messaggio di eccezione contiene informazioni sul motivo dell'eccezione. Tuttavia, quando viene creata una nuova eccezione, le informazioni su quella precedente potrebbero essere eliminate permanentemente. Questo è simile all'esempio precedente in cui StackTrace può essere rimosso a causa della generazione di una nuova eccezione.

Nessuna ricerca di eccezioni specifiche

A volte agli sviluppatori piace andare sul sicuro quando gestiscono le eccezioni. A volte questo è facile da fare. Ma rilevare java.lang.Exception invece di un'eccezione specifica non è accettabile. try{ File file = new File(""); file.getCanonicalPath(); }catch(Exception exe){ throw new MyException("Problem in data reading."); }

Prendi e lancia non necessario

Cattura le eccezioni se desideri convertirle in un altro tipo o se ti aiuta ad aggiungere alcune informazioni al messaggio di eccezione per l'utente finale o l'analista. Altrimenti, semplicemente gettali via ulteriormente nella firma del metodo (usando i lanci) invece di catturarli.

Cattura RuntimeException

Consiglierei di evitare di rilevare RuntimeException. Invece, è meglio cogliere eccezioni specifiche e trattarle.

Trovare eccezioni non controllate

È un argomento controverso se catturare o meno le eccezioni non controllate. NullPointerException e ArrayIndexOutOfBound potrebbero essere i migliori esempi di eccezioni non controllate. Invece di rilevare queste eccezioni, puoi modificare il codice per gestire questi scenari. Ad esempio, per evitare NullPointerException, per garantire che tutte le variabili siano inizializzate, per evitare eccezioni ArrayIndexOutOfBound, per definire un array della lunghezza corretta, ecc.

Problemi relativi alla registrazione delle eccezioni

La rivista aiuterà il secondo interessato, cioè colui che analizza il problema. A volte uno sviluppatore esagera con i file di registro e i registri vengono creati a ogni livello dell'applicazione. Il log dovrebbe registrare l'eccezione al livello in cui si è verificata. Sembra ottimale visualizzare un avviso che si è verificata un'eccezione, con una proposta di interrompere o continuare l'esecuzione del programma e la registrazione obbligatoria dell'eccezione nel registro.

Eccezione del controllo di flusso

Un'eccezione è un'interruzione del normale flusso del programma, il che significa che è necessario interrompere questo flusso e informarne l'utente finale. Se aggiungiamo una chiamata al metodo che è un thread alternativo, ciò porterà a enormi problemi di manutenzione. try{ myObject.getValue(); }catch(NullPointerException npe){ alternateMethod(); }

Uso onnipresente di java.lang.Exception

Inoltre, non è una buona idea utilizzare java.lang.Exception ovunque per qualsiasi eccezione. È invece preferibile utilizzare eccezioni specifiche dell'applicazione o le eccezioni Java standard più appropriate. Articolo originale: Errori comuni nella gestione delle eccezioni Tradotto e doppiato da: Ve4niY