Il debug

Come nel caso del tracing, anche il debugging può essere attivato da web.config oppure dalla singola pagina.

L'utilità del debugging è palese, perchè permette di visualizzare un messaggio dettagliato sull'errore che si è generato, che il più delle volte consente di porvi rimedio in maniera abbastanza semplice.
Può capitare di utilizzare una variabile nulla, oppure senza averla instanziata, ed è in casi come questi che qualcosa di più di "si è verificato un errore", o peggio ancora di un funzionamento non regolare dell'applicazione, risulta di aiuto.
Ecco ad esempio cosa accade se utilizzando VB.NET, cercate di mandare in output il valore di una variabile che non è stata dichiarata:

Per attivare il debug su una singola pagina, basta aggiungere la proprietà "Debug" alla direttiva Page, come nell'esempio:

Gestione avanzata degli errori

Questo primo approccio appena analizzato può andare bene per debuggare una singola pagina, su base occasionale o durante lo sviluppo.
In situazioni normali, tuttavia, è opportuno non abilitare questa funzionalità, altrimenti, come potete notare dalla figura precedente, si corre il rischio di mostrare frammenti di codice ai nostri utenti.

Così come per il tracing, è possibile abilitare il debugging, tramite web.config, solo sulla rete locale. Vediamo come fare, aggiungendo sempre queste informazioni all'interno della sezione system.web:

In realtà in questo esempio abbiamo fatto molto di più. Abbiamo sì attivato il debugging, ma attraverso la sezione CustomErrors, abbiamo impostato lo stesso solo su base locale, rimandando i nostri utenti in caso di errore ad una pagina /error.aspx che potrebbe contenere un avviso.
Da notare come sia possibile specificare, attraverso l'utilizzo di una sezione error, un handler differente per ogni codice di stato corrispondente ad un errore. Nel nostro esempio, abbiamo deciso di utilizzare per l'errore 404 (Page Not Found - Pagina non trovata) uno script ASP.NET differente. Ovviamente, nulla ci vieta di gestire l'errore attraverso uno script ASP o una normale pagina HTML.

Ecco cosa vedranno invece i nostri utenti, nel caso di un errore:

Infine, per abilitare il debugging su una singola, pagina, è sufficiente utilizzare questa istruzione:

Conclusioni

Come abbiamo avuto modo di vedere, ASP.NET si distingue da ASP per la grande flessiblità ed una facilità di configurazione che non trova analogie nella controparte.
Come avrete sicuramente capito, uno degli svantaggi maggiori delle classic ASP rispetto ad altre tecnologie sta proprio negli strumenti di tracing e debugging, specie in caso di applicazioni abbastanza complesse.
ASP.NET raccoglie tutto quanto di buono le ASP hanno significato in questi anni, introducendo allo stesso tempo funzionalità di tracing e debugging, tanto per cominciare, degne davvero di un framework potente e ben congeniato, che deve tenere conto senza ombra di dubbio di tutta una serie di problematiche come queste, che hanno un'importanza basilare per lo sviluppatore, facilitandolo in una delle fasi più delicate di tutto il ciclo di produzione.

Su debbuing e tracing, ASP.NET batte ASP 2-0. Palla al centro.

Contenuti dell'articolo

• Pagina 1
  • Il tracing
  • Trace.write
• Pagina 2
  • Il debug
  • Gestione avanzata degli errori
  • Conclusioni

• Galleria fotografica dinamica con ASP.NET AJAX
• Usare Search come un servizio nei tuoi siti e nei tuoi client
• Mappe nel tuo sito con Virtual Earth
• Integrare Windows Live ID, Contacts e Presence API nelle tue applicazioni
• Introduzione ai cloud based service con Windows Live Services
• Realizzare un custom extender AJAX con ASP.NET 3.5
• Tracciare le modifiche ai dati e allineare i datawarehouse con il Change Data Capture in SQL Server 2008
• Le nuove caratteristiche di IIS 7.0 per sviluppatori e sistemisti