DEV Community 👩‍💻👨‍💻

Cover image for Tips & Tricks: loggare le nostre applicazioni
Marco Santoni
Marco Santoni

Posted on • Updated on

Tips & Tricks: loggare le nostre applicazioni

Vi è mai capitato di avere un’applicazione, ormai rilasciata in ambiente di produzione, che non funziona come dovrebbe? Magari per un qualche subdolo errore sfuggito durante la fase di test. Immagino di sì.
Se c’è un’eccezione è relativamente facile, l’oggetto Exception ci offre la possibilità di vedere lo stack trace delle chiamate e capiamo subito dove si è verificato il problema. Ma quando l’errore è logico? Come possiamo fare a districarci in quella giungla fatta di codice? Se siamo stati bravi (e noi dev non lo siamo mai) abbiamo messo dei messaggi di log per aiutarci a monitorare come sta lavorando la nostra applicazione ma, quando questa è complessa, è difficile orientarsi tra questi messaggi. E spesso questi messaggi sono ingannevoli. In 20 anni di lavoro e, per buona parte della mia carriera, sono stato consulente per diverse aziende ed ho visto più e più volte log e trace inutili. Uno dei peggiori che ho trovato è il messaggio che ci indica l’inizio e la fine della procedura.
Lo so, state pensando che sono impazzito. Calma, vi spiego subito perché questa mia affermazione.
Ho scritto questo non perché questi messaggi non servono a nulla, il contrario è un’informazione preziosa ma, se questi messaggi sono messi male e/o a caso, possono portare a perdere moltissimo tempo durante la fase di debug. Succede infatti spesso che ad esempio i messaggi sono messi in modo sbagliato. Magari non viene scritto neppure il nome del metodo. Magari, causa un copia-incolla, con il nome errato. Magari con il tempo il nome del metodo ha cambiato nome. Il massimo che ho trovato è stato quando nella procedura c’è il messaggio “Inizio metodo: xxx” e poi finisce con “Fine metodo: yyy”. E cosa facciamo in genere? Cominciamo a mettere altri messaggi qua e là, cercando di “restringere il cerchio” fino a riuscire ad individuare il blocco di codice incriminato. Messaggi che nella migliore delle ipotesi non toglieremo più ed al prossimo giro di giostra sarà ancora e sempre più difficile trovare l'errore.
Ora, dopo essermi accorto che sono partito a scrivere questo post con il buon proposito di essere rapido e mi sono trovato ad aver scritto troppo, vediamo cosa possiamo fare per mitigare un po' questa situazione. Prendiamo come esempio i log appena citati e vediamo come con .NET possiamo quantomeno riuscire a fare in modo che i messaggi siano veritieri. Infatti, .NET, ci mette a disposizione degli attributi che ci permettono di avere alcune informazioni utili a noi dev quando dobbiamo fare dei debug. Gli attributi di cui parlo sono:

  • CallerMemberName: Nome del metodo.
  • CallerFilePathAttribute: Percorso del file.
  • CallerLineNumberAttribute: Numero di riga.
  • CallerArgumentExpression: Espressione passata al metodo (a partire da .NET 6, non lo tratterò in questo articolo).

Vediamo come possiamo utilizzare questi attributi per creare un a classe di log funzionale.

    class LogService
    {
        public void Info(string message, [CallerMemberName] string callerMemberName = "",
            [CallerFilePathAttribute] string callerFilePathAttribute = "",
            [CallerLineNumberAttribute] int callerLineNumberAttribute = -1)
        {
            Console.WriteLine($"{callerMemberName} :: {message} at line {callerLineNumberAttribute} in file {callerFilePathAttribute}");
        }
    }
Enter fullscreen mode Exit fullscreen mode

Nella classe di log qui sopra ho creato, per brevità, solo il metodo Info. In una vera classe di log bisognerebbe gestire anche i messaggi di Debug, Error, ecc. Questo lo lascio a voi ed alla vostra inventiva e sono certo che non avrete problemi nel farlo.

Per concludere

Lo confesso, il post l'ho scritto un po' "così", senza pensarci troppo e senza rivederlo, diciamo "di getto". Volevo farlo prima che questo 2021 si concludesse in modo da riuscire a scrivere ancora una volta qualcosa di (spero) utile. Ho scritto questo post solo perché mi serviva una scusa per augurare a tutti buon anno ma non volevo usare un post solo per questo. Ci tenevo anche a concludere il 2021 con una pillola nella speranza che questa aiuti qualche dev a migliorare le proprie sessioni di debug.

Concludo quindi facendo a tutti i miei più sinceri auguri di Buon Anno nella speranza che il 2022 sia un anno ancora migliore di quello che è passato.

PS. Magari nei prossimi giorni rivedrò questo articolo aggiornandolo, correggendolo e/o integrandolo. Per il momento va bene così.

Top comments (0)

🌚 Friends don't let friends browse without dark mode.

Sorry, it's true.