“Bad Coding/Designing Practices”: Usare parametri di output per ritornare dettagli su errori applicativi

Bad Coding/Designing Practices, Ingegneria del Software 0 19
Subject
“Errors Handling”

Bad Practice
Usare parametri di output per ritornare dettagli su errori applicativi

Explanation
Inserire dei parametri di output (tipicamente “errorcode” e “errormessage”) sulla firma del metodo che vuole/deve comunicare al “client” l’eventuale errore applicativo che si verifica durante l’esecuzione

Problem
Per potere restituire in output del nostro metodo/procedura le informazioni che riguardano un errore è necessario fare “wrapping” di tutti gli errori che si possono verificare (errori applicativi o exception di runtime). Ciò spesso è molto complicato, perchè non tutti gli scenari d’errore sono prevedibili in fase di scrittura del codice (soprattutto nelle situazioni in cui il nostro codice risulta essere un po’ più complesso). Questa cosa potrebbe portare a non fare emergere, in alcuni casi, certi errori verificatisi durante l’esecuzione.

Fix
Non utilizzare parametri specifici di output per restituire le informazioni riguardanti gli errori. Se il nostro linguaggio fornisce supporto al “Exception Handling” usare una Exception come “portatrice” delle informazioni riguardanti un errore. Questo approccio “costringerà” il client del nostro metodo/procedura a prevedere la ricezione di Exception (alcune lanciate esplicitamente da codice, altre di runtime che si possono verificare spontaneamente), e a recuperare i dettagli dell’errore dalla Exception stessa (codice errore e descrizione).
Su Oracle DB, ad esempio, dalle “Stored Procedure” è anche possibile lanciare (raise) delle Exception “custom”, per mappare tutti i nostri errori applicativi.

raise_application_error(
error_number, message[, {TRUE | FALSE}]);
where error_number is a negative integer in the range -20000 .. -20999 and message is a character string up to 2048 bytes long. If the optional third parameter is TRUE, the error is placed on the stack of previous errors. If the parameter is FALSE (the default), the error replaces all previous errors. RAISE_APPLICATION_ERROR is part of package DBMS_STANDARD, and as with package STANDARD, you do not need to qualify references to it.

Note
Si consiglia di consultare la BadPractice “Catching “indiscriminato” di tutte le Exception

Scope
Linguaggio Java, C#, PL/SQL e tutti i linguaggi con supporto al “Exception Handling”

About the author / 

Salvatore Di Loro

Related Posts

Leave a reply

Your email address will not be published. Required fields are marked *

Instagram

Flickr