Poi purtroppo, poiché sarei stato assunto in qualità di programmatore, sono obbligato ad aprire il codice e, per colpa del mio animo molto sensibile ed emotivo, mi incupisco profondamente quando leggo cose del genere:
void metodogenerico(Tipo argomentogenerico) throws Exception {
...
}
Se consideriamo poi che una firma di questo tipo è presente in TUTTO il progetto, allora inizio ad incazzarmi come una iena!
Quel maledetto throws Exception è uno dei peggiori antipattern usati da chi non ha mai capito come funzioni la gestione delle eccezioni in un qualsiasi linguaggio OOP e che secondo me dovrebbe provare un altro mestiere... tipo andare a zappare la terra che così danni non ne crea.
La cosa peggiore di questo antipattern non è solo l'utilizzo in sé ma il danno che ne consegue poi su tutti i metodi chiamanti. Eh si perché se il primo programmatore imbecille scrive una ciofeca del genere, costringe poi tutti gli altri che lavorano sui chiamanti a fare la stessa cosa. In realtà se il metodo incriminato fosse uno solo, basterebbe anche un solo programmatore serio a correggere immediatamente l'errore prima del diffondersi il virus. Peccato che questo non accade, vuoi per pigrizia oppure per la stessa imbecillità che ha portato il primo a scrivere la ciofeca.
Si arriva quindi al giorno in cui su una certa Action struts io debba chiamare un metodo che rilancia Exception, che a sua volta chiama un metodo che rilancia Exception, che a sua volta ancora... eccetera eccetera, fino ad arrivare in Cina con la stessa metodologia (la lunghezza dello stacktrace è talmente lungo che ricopre sicuramente una distanza simile a Roma-Pechino in linea aerea) , quando però devo creare una logica di gestione degli errori.
PECCATO che durante tutto il flusso fino al backend, potrebbero avvenire eccezioni GESTITE di varia natura, dalla chiamata fallita ad un webservice fino ad un semplice controllo di formato di un parametro.
PECCATO che io dovrei mettere la richiesta in errore solo per alcuni casi specifici mentre per altri no.
PECCATO che apparentemente non ci sia differenza tra una connessione down del webservice o il formato sbagliato di un parametro, poiché in tutti e due i casi si lancia la stessa checked exception ma con message diverso
PECCATO che non posso rifattorizzare un cazzo perché questo significherebbe perdere più tempo rispetto al dover rifare tutto il modulo d'accapo.
PECCATO che nessuno si sia mai accorto di questo problema di cattivo design, continuando imperterrito a scrivere i propri metodi con la ciofeca descritta sopra
PECCATO che devo essere sempre io l'unico idiota ad incazzarmi per una cosa del genere quando per tutto il resto del mondo va bene!
La ciliegina sulla torta è che su questo progetto la gestione di messaggi di errori provenienti dal backend viene fatto nel seguente modo
private void validateParametro(Tipo parametro, List<String> messaggiDiErrore) {
...
}
private void metodoDiBusiness(vari parametri, List<String> messaggiDiErrore) {
...
}
validateParametro(param1, messaggiDiErrore);
validateParametro(param1, messaggiDiErrore);
if(!messaggiDiErrore.isEmpty) {
gestisci errore
interrompi esecuzione action
}
validateParametro(param2, messaggiDiErrore);
if(!messaggiDiErrore.isEmpty) {
gestisci errore
interrompi esecuzione action
}
metododiBusiness(vari parametri, messaggiDiErrore);
if(!messaggiDiErrore.isEmpty) {
gestisci errore
interrompi esecuzione action
}
Ovviamente chi ha ideato una cosa del genere non si è minimamente immaginato che una Exception è anche un oggetto istanziato da una classe! Quindi magari poteva pure creare una checked exception, con all'interno il suddetto array di messaggi ed usare semplicemente un bel try catch! Ma no... meglio ridondare il codice ed evitare di usare sapientemente le eccezioni, anche se dovresti essere considerato un Senior Java Consultant.
Rilanciamo sempre al chiamante la patata bollente, tanto prima o poi il coglione che lo dovrà cucinare ci sarà.
Cioè io.
Nessun commento:
Posta un commento