Il nome del metodo in esecuzione

pubblicato il 10/09/2007

I programmatori più anziani (quelli che hanno fatto in tempo a conoscere un mondo senza IDE e breakpoint), erano (sono?) abituati ad andare a cercare i bug delle applicazioni piazzando nei punti strategici delle stesse delle stampe (a video e/o su carta) del tipo "Procedura X - Avvio", "Procedura X - Calcolo Totale", "Procedura X - Fine" e così via; normalmente la tecnica era molto più raffinata di come la descrivo: ad esempio, la stampa poteva essere subordinata ad un parametro dell'applicazione così da non apparire in produzione, ma solo in fase di debug, poteva comprendere i valori delle variabili o di ritorno dalle funzioni e così via. Lanciando l'applicazione e leggendo l'output di questi programmi si cercava di capire la zona del codice dove qualcosa poteva essere andato storto.

Visual Studio.NET, come i suoi predecessori e molti altri ambienti di sviluppo, permette di inserire dei breakpoint in determinati punti dell'applicazione così che l'esecuzione (purchè lanciata dall'interno di Visual Studio, ovviamente) si interrompa consentendoci di interrogare il valore delle variabili e di proseguire passo a passo, nella speranza di trovare l'errore. Purtroppo però vi sono circostanze in cui questo approccio non è sufficiente; l'ambiente di produzione è ovviamente differente da quello di sviluppo / test per almeno tre variabili: utente, configurazione del sistema, set di dati; in questi casi si rende necessario ritornare al buon vecchio file di log per capire cosa ha fatto l'utente, in quale ambiente e con quali dati.

Non descriverò qui la creazione di un sistema di logging/tracing, ma mi limito a considerare che questo si basa su un presupposto: ogni riga di codice tracciate deve essere ricondotta in maniera univoca al metodo che l'ha generata: il metodo più semplice consiste nel ripetere svariate volte nel codice istruzioni del tipo:

Console.Writeline("Sub X - 001")
....
Console.Writeline("Sub X - 002")

e così via...

Questo metodo però si basa su un uso sagace della funzionalità di "Copia & Incolla": copio l'istruzione di WriteLine, modificando la stringa ogni volta che la incollo da qualche altra parte; essendo un'attività umana, è soggetta ad errori (lo posso assicurare...)

Il Framework .NET però ci viene in soccorso, usando la classe StackFrame contenuta nella namespace System.Diagnostic: questa classe consente, in qualunque punto dell'applicazione ci ritroviamo, di risalire lo stack di esecuzione per ottenere il nome del metodo in esecuzione, la classe cui appartiene il metodo e la namespace cui appartiene la classe; purtroppo però la classe consente di recuperare soltanto il nome ed il tipo dei parametri eventualmente passati al metodo, ma non il loro valore effettivo.

Public Function RunningContext() As String

  Dim result As String
  Dim sFrame As System.Diagnostics.StackFrame

  sFrame = New System.Diagnostics.StackFrame(1)
  result = sFrame.GetMethod().ReflectedType + "." + sFrame.GetMethod().Name + "()"

  Return result

End Function