Horror 'Code Refactoring' Story - Exception per tutti

La scorsa settimana -durante un code refactoring- mi e’ tornato alla menta un fatto successo in passato lavorando su del codice altrui. Siccome la mia memoria non e’ delle migliori, ho deciso di metterlo nero su bianco dando seguito alla rubrica coding horror stories inaugurata lo scorso mese col post string.replace: Sai farlo? Oppure inventi la ruota?

Il Contesto: Prima di procedere col racconto di questa esperienza vorrei fare il punto sul contesto del Code Refactoring incriminato. Dovevo fare una modifica abbastanza idiota a del codice altrui. Probabilmente anche il mio gatto con un solo occhio sarebbe riuscito a fare quella modifica eliminando il bug originale.

try / catch

Oltre ad avere sistemato il bug in questione mi sono spinto un attimo oltre. Ho deciso di riorganizzare il codice in modo sensato e soprattutto di non “nascondere la polvere sotto il tappeto facendo lo gnorri”.

In che senso? Per farla breve il codice aveva la seguente impronta:

1
2
3
4
5
6
7
8

try
{
    // code ...
}
catch(Exception ex)
{
    // do nothing
}

Vi lascio immaginare il vedere una serie di metodi impostati in questo modo. Inoltre vogliamo parlare di non avere “bugs” in quanto non ci sono (=non si vedono) scoppiamenti dell’applicazione?

Code Refactoring

Il Code Refactoring da parte mia e’ stato molto semplice e non ha “stravolto” il codice. Ho cambiato il catch nel seguente modo:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

try
{
    // code ...
}
catch(Exception ex)
{
    // Step 0 - Log Exception
    // Step 1 - Throw Exception
    throw ex;
}

Indovinate? A questo punto il “tappeto” e’ sparito e la polvere ha cominciato a vedersi. A quel punto era il mio codice che generava dei bugs che prima non esistevano.

Bugs, come gestirli?

Ora vi pongo un quesito -da developer a developer- come vi comportate coi bugs nel codice?

• insabbiate?
• Fate esplodere brutalmente il tutto?
• Intercettato e tracciato l’errore fate risalire dei messaggi umani alla UI?

Secondo me non esiste una regola fissa, ma dipende dal contesto in cui mi trovo. In che senso?

• API di BE verso FE: torno un codice/ messaggio d’errore per l’utente
• API di BE: faccio esplodere brutalmente dopo avere tracciato l’errore

Un esempio? Personalmente preferisco aprire il monitor di una Azure Function e vedere dei rossi (oppure dei Failures su Application Insight) che tutto verde senza un minimo problema. Inoltre, vi ricordo che un bug puo’ sporcare i dati ed accorgersene troppo tardi e’ spesso un problema.

Links

• AndreaCarratta@Linkedin
• BugsInCloud@YouTube