Elaborazione delle eccezioni non gestite (VB)

  • Articolo

di Scott Mitchell

Visualizzare o scaricare il codice di esempio (procedura per il download)

Quando si verifica un errore di runtime in un'applicazione Web nell'ambiente di produzione, è importante inviare una notifica a uno sviluppatore e registrare l'errore in modo che possa essere diagnosticato in un secondo momento. Questa esercitazione fornisce una panoramica del modo in cui ASP.NET elabora gli errori di runtime e esamina un modo per avere codice personalizzato eseguito ogni volta che un'eccezione non gestita bolle fino al runtime di ASP.NET.

Introduzione

Quando si verifica un'eccezione non gestita in un'applicazione ASP.NET, viene visualizzata una bolla fino al runtime di ASP.NET, che genera l'evento e visualizza la Error pagina di errore appropriata. Esistono tre diversi tipi di pagine di errore: l'errore di runtime giallo schermata di morte (YSOD); Dettagli eccezione YSOD; e pagine di errore personalizzate. Nell'esercitazione precedente è stata configurata l'applicazione per usare una pagina di errore personalizzata per gli utenti remoti e i dettagli dell'eccezione YSOD per gli utenti che visitano in locale.

L'uso di una pagina di errore personalizzata descrittiva che corrisponde all'aspetto e all'aspetto del sito è preferibile per l'errore di runtime YSOD predefinito, ma la visualizzazione di una pagina di errore personalizzata è solo una parte di una soluzione di gestione completa degli errori. Quando si verifica un errore in un'applicazione in produzione, è importante che gli sviluppatori ricevano una notifica dell'errore in modo che possano annullare la causa dell'eccezione e risolverla. Inoltre, i dettagli dell'errore devono essere registrati in modo che l'errore possa essere esaminato e diagnosticato in un secondo momento.

Questa esercitazione illustra come accedere ai dettagli di un'eccezione non gestita in modo che possano essere registrati e una notifica per sviluppatori. Le due esercitazioni seguenti illustrano le librerie di registrazione degli errori che, dopo un po' di configurazione, notificano automaticamente agli sviluppatori errori di runtime e registrano i dettagli.

Nota

Le informazioni esaminate in questa esercitazione sono più utili se è necessario elaborare eccezioni non gestite in modo univoco o personalizzato. Nei casi in cui è necessario registrare l'eccezione e inviare una notifica a uno sviluppatore, usando una libreria di registrazione degli errori è il modo per procedere. Le due esercitazioni successive forniscono una panoramica di due librerie di questo tipo.

Esecuzione del codice quando viene generato l'eventoError

Gli eventi forniscono un meccanismo per segnalare che si è verificato un elemento interessante e che un altro oggetto deve eseguire il codice in risposta. Come sviluppatore di ASP.NET si è abituati a pensare in termini di eventi. Se si vuole eseguire un codice quando il visitatore fa clic su un determinato pulsante, si crea un gestore eventi per l'evento Click di Button e si inserisce il codice. Dato che il runtime di ASP.NET genera Error l'evento ogni volta che si verifica un'eccezione non gestita, il codice per registrare i dettagli dell'errore verrà inserito in un gestore eventi. Ma come si crea un gestore eventi per l'evento Error ?

L'evento Error è uno di molti eventi nella HttpApplication classe generata in determinate fasi della pipeline HTTP durante la durata di una richiesta. Ad esempio, l'evento della classe viene generato all'inizio di ogni richiesta. AuthenticateRequest L'eventoHttpApplication viene generato quando un modulo di BeginRequest sicurezza ha identificato il richiedente. Questi HttpApplication eventi forniscono allo sviluppatore di pagina un mezzo per eseguire la logica personalizzata nei vari punti della durata di una richiesta.

I gestori eventi per gli HttpApplication eventi possono essere inseriti in un file speciale denominato Global.asax. Per creare questo file nel sito Web, aggiungere un nuovo elemento alla radice del sito Web usando il modello di classe applicazione globale con il nome Global.asax.

Screenshot dell'aggiunta di un nuovo elemento alla radice del sito Web usando il modello di classe applicazione globale con il nome Global.asax per creare questo file nel sito Web.

Figura 1: Aggiungere Global.asax all'applicazione Web
(Fare clic per visualizzare l'immagine full-size)

Il contenuto e la Global.asax struttura del file creato da Visual Studio differiscono leggermente in base al fatto che si usi un progetto applicazione Web (WAP) o un progetto sito Web (WSP). Con un WAP, l'oggetto Global.asax viene implementato come due file separati e Global.asaxGlobal.asax.vb. Il file contiene nulla ma una @Application direttiva che fa riferimento al Global.asax.vb.vb file. I Global.asax gestori eventi di interesse sono definiti nel file. Per i provider di servizi di rete, viene creato solo un singolo file e Global.asaxi gestori eventi vengono definiti in un <script runat="server"> blocco.

Il Global.asax file creato in un modello di classe applicazione globale di Visual Studio include gestori eventi denominati Application_BeginRequest, e , che sono gestori eventi per gli HttpApplication eventi AuthenticateRequestBeginRequest, Application_AuthenticateRequeste Application_Error, rispettivamenteError. Esistono anche gestori eventi denominati Application_Start, Session_Start, Application_Ende Session_End, che sono gestori eventi che vengono attivati rispettivamente all'avvio dell'applicazione Web, all'avvio di una nuova sessione, al termine dell'applicazione e alla fine di una sessione. Il Global.asax file creato in un WSP di Visual Studio contiene solo i Application_Errorgestori eventi , , Application_StartSession_Start, Application_Ende Session_End .

Nota

Quando si distribuisce l'applicazione ASP.NET è necessario copiare il Global.asax file nell'ambiente di produzione. Il Global.asax.vb file creato nel WAP non deve essere copiato nell'ambiente di produzione perché questo codice viene compilato nell'assembly del progetto.

I gestori eventi creati dal modello di classe di applicazione globale di Visual Studio non sono esaustivi. È possibile aggiungere un gestore eventi per qualsiasi HttpApplication evento assegnando al gestore Application_EventNameeventi . Ad esempio, è possibile aggiungere il codice seguente al Global.asax file per creare un gestore eventi per l'eventoAuthorizeRequest:

Sub Application_AuthorizeRequest(ByVal sender As Object, ByVal e As EventArgs)
    ' Event handler code
End Sub

Analogamente, è possibile rimuovere tutti i gestori eventi creati dal modello di classe applicazione globale che non sono necessari. Per questa esercitazione è necessario solo un gestore eventi per l'evento Error ; è possibile rimuovere gli altri gestori eventi dal Global.asax file.

Nota

I moduli HTTP offrono un altro modo per definire gestori eventi per HttpApplication gli eventi. I moduli HTTP vengono creati come file di classe che possono essere inseriti direttamente all'interno del progetto applicazione Web o separati in una libreria di classi separata. Poiché possono essere separati in una libreria di classi, i moduli HTTP offrono un modello più flessibile e riutilizzabile per la creazione HttpApplication di gestori eventi. Mentre il Global.asax file è specifico dell'applicazione Web in cui risiede, i moduli HTTP possono essere compilati in assembly, a questo punto l'aggiunta del modulo HTTP a un sito Web è semplice come eliminare l'assembly nella Bin cartella e registrare il modulo in Web.config. Questa esercitazione non esamina la creazione e l'uso di moduli HTTP, ma le due librerie di registrazione degli errori usate nelle due esercitazioni seguenti vengono implementate come moduli HTTP. Per altre informazioni sui vantaggi dei moduli HTTP, vedere Uso di moduli HTTP e gestori per creare componenti ASP.NET pluggable.

Recupero di informazioni sull'eccezione non gestita

A questo punto è disponibile un file Global.asax con un Application_Error gestore eventi. Quando questo gestore eventi viene eseguito, è necessario inviare una notifica a uno sviluppatore dell'errore e registrarne i dettagli. Per eseguire queste attività è prima necessario determinare i dettagli dell'eccezione generata. Utilizzare il metodo dell'oggetto GetLastError Server per recuperare i dettagli dell'eccezione non gestita che ha causato l'attivazione dell'eventoError.

Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
    ' Get the error details
    Dim lastErrorWrapper As HttpException = _
        CType(Server.GetLastError(), HttpException)
End Sub

Il GetLastError metodo restituisce un oggetto di tipo , ovvero il tipo Exceptiondi base per tutte le eccezioni in .NET Framework. Tuttavia, nel codice precedente si esegue il cast dell'oggetto Exception restituito da GetLastError in un HttpException oggetto. Se l'evento viene attivato perché un'eccezione è stata generata durante l'elaborazione Error di una risorsa ASP.NET, l'eccezione generata viene sottoposta a wrapping all'interno di un HttpExceptionoggetto . Per ottenere l'eccezione effettiva che ha precipitato l'evento Error usa la InnerException proprietà . Se l'evento Error è stato generato a causa di un'eccezione basata su HTTP, ad esempio una richiesta per una pagina non esistente, HttpException viene generata un'eccezione interna.

Il codice seguente usa l'oggetto GetLastErrormessage per recuperare informazioni sull'eccezione che ha attivato l'evento, archiviando l'oggetto ErrorHttpException in una variabile denominata lastErrorWrapper. Archivia quindi il tipo, il messaggio e la traccia stack dell'eccezione di origine in tre variabili di stringa, verificando se l'eccezione lastErrorWrapper è l'eccezione effettiva che ha attivato l'evento (nel caso di eccezioni basate su HTTP) o se è semplicemente un wrapper per un'eccezione generata durante l'elaborazione Error della richiesta.

Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
    ' Get the error details
    Dim lastErrorWrapper As HttpException = _
        CType(Server.GetLastError(), HttpException)

    Dim lastError As Exception = lastErrorWrapper
    If lastErrorWrapper.InnerException IsNot Nothing Then
        lastError = lastErrorWrapper.InnerException
    End If

    Dim lastErrorTypeName As String = lastError.GetType().ToString()
    Dim lastErrorMessage As String = lastError.Message
    Dim lastErrorStackTrace As String = lastError.StackTrace
End Sub

A questo punto sono disponibili tutte le informazioni necessarie per scrivere codice che registra i dettagli dell'eccezione in una tabella di database. È possibile creare una tabella di database con colonne per ogni dettagli dell'errore di interesse, ovvero il tipo, il messaggio, la traccia dello stack e così via, insieme ad altre informazioni utili, ad esempio l'URL della pagina richiesta e il nome dell'utente attualmente connesso. Application_Error Nel gestore eventi si connetterà quindi al database e si inserisce un record nella tabella. Analogamente, è possibile aggiungere codice per avvisare uno sviluppatore dell'errore tramite posta elettronica.

Le librerie di registrazione degli errori esaminate nelle due esercitazioni successive forniscono tali funzionalità fuori dalla casella, quindi non è necessario compilare la registrazione e la notifica di questo errore. Tuttavia, per illustrare che l'evento viene generato e che il ErrorApplication_Error gestore eventi può essere usato per registrare i dettagli degli errori e inviare una notifica a uno sviluppatore, aggiungere codice che notifica a uno sviluppatore quando si verifica un errore.

Notifica a uno sviluppatore quando si verifica un'eccezione non gestita

Quando si verifica un'eccezione non gestita nell'ambiente di produzione, è importante avvisare il team di sviluppo in modo che possano valutare l'errore e determinare quali azioni devono essere eseguite. Ad esempio, se si verifica un errore nella connessione al database, è necessario controllare il stringa di connessione e, ad esempio, aprire un ticket di supporto con l'azienda di hosting Web. Se l'eccezione si è verificata a causa di un errore di programmazione, potrebbe essere necessario aggiungere codice o logica di convalida aggiuntivi per evitare tali errori in futuro.

Le classi .NET Framework nello spazio dei nomi semplificano l'invioSystem.Net.Mail di un messaggio di posta elettronica. La MailMessage classe rappresenta un messaggio di posta elettronica e ha proprietà come To, From, Subject, Bodye Attachments. Viene usato per inviare un oggetto usando un MailMessage server SMTP specificato. Le SmtpClass impostazioni del server SMTP possono essere specificate a livello di codice o dichiarativo nell'elemento<system.net>Web.config filein . Per altre informazioni sull'invio di messaggi di posta elettronica in un'applicazione ASP.NET, vedere l'articolo Invio di Email da un sito Pagine Web ASP.NET e le domande frequenti su System.Net.Mail.

Nota

L'elemento <system.net> contiene le impostazioni del server SMTP usate dalla classe durante l'invio SmtpClient di un messaggio di posta elettronica. Probabilmente l'azienda di hosting Web ha un server SMTP che è possibile usare per inviare messaggi di posta elettronica dall'applicazione. Per informazioni sulle impostazioni del server SMTP da usare nell'applicazione Web, consultare la sezione del supporto dell'host Web.

Aggiungere il codice seguente al Application_Error gestore eventi per inviare un messaggio di posta elettronica per lo sviluppatore quando si verifica un errore:

Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
    ' Get the error details
    Dim lastErrorWrapper As HttpException = _
        CType(Server.GetLastError(), HttpException)
    
    Dim lastError As Exception = lastErrorWrapper
    If lastErrorWrapper.InnerException IsNot Nothing Then
        lastError = lastErrorWrapper.InnerException
    End If

    Dim lastErrorTypeName As String = lastError.GetType().ToString()
    Dim lastErrorMessage As String = lastError.Message
    Dim lastErrorStackTrace As String = lastError.StackTrace

    Const ToAddress As String = "support@example.com"
    Const FromAddress As String = "support@example.com"
    Const Subject As String = "An Error Has Occurred!"

    ' Create the MailMessage object
    Dim mm As New MailMessage(FromAddress, ToAddress)
    mm.Subject = Subject
    mm.IsBodyHtml = True
    mm.Priority = MailPriority.High
  mm.Body = string.Format( _
"<html>" & vbCrLf & _
"  <body>" & vbCrLf & _
"  <h1>An Error Has Occurred!</h1>" & vbCrLf & _
"  <table cellpadding=""5"" cellspacing=""0"" border=""1"">" & vbCrLf & _
"  <tr>" & vbCrLf & _
"  <tdtext-align: right;font-weight: bold"">URL:</td>" & vbCrLf & _
"  <td>{0}</td>" & vbCrLf & _
"  </tr>" & vbCrLf & _
"  <tr>" & vbCrLf & _
"  <tdtext-align: right;font-weight: bold"">User:</td>" & vbCrLf & _
"  <td>{1}</td>" & vbCrLf & _
"  </tr>" & vbCrLf & _
"  <tr>" & vbCrLf & _
"  <tdtext-align: right;font-weight: bold"">Exception Type:</td>" & vbCrLf & _
"  <td>{2}</td>" & vbCrLf & _
"  </tr>" & vbCrLf & _
"  <tr>" & vbCrLf & _
"  <tdtext-align: right;font-weight: bold"">Message:</td>" & vbCrLf & _
"  <td>{3}</td>" & vbCrLf & _
"  </tr>" & vbCrLf & _
"  <tr>" & vbCrLf & _
"  <tdtext-align: right;font-weight: bold"">Stack Trace:</td>" & vbCrLf & _
"  <td>{4}</td>" & vbCrLf & _
"  </tr> " & vbCrLf & _
"  </table>" & vbCrLf & _
"  </body>" & vbCrLf & _
"</html>", _
  Request.RawUrl, _
  User.Identity.Name, _
  lastErrorTypeName, _
  lastErrorMessage, _
  lastErrorStackTrace.Replace(Environment.NewLine, "<br />"))

    'Attach the Yellow Screen of Death for this error
    Dim YSODmarkup As String = lastErrorWrapper.GetHtmlErrorMessage()
    If Not String.IsNullOrEmpty(YSODmarkup) Then
        Dim YSOD As Attachment = _
            Attachment.CreateAttachmentFromString(YSODmarkup, "YSOD.htm")
        mm.Attachments.Add(YSOD)
    End If

    ' Send the email
    Dim smtp As New SmtpClient()
    smtp.Send(mm)
End Sub

Anche se il codice precedente è abbastanza lungo, la maggior parte di essa crea il codice HTML visualizzato nel messaggio di posta elettronica inviato allo sviluppatore. Il codice inizia facendo riferimento al HttpException metodo restituito dal GetLastError metodo (lastErrorWrapper). L'eccezione effettiva generata dalla richiesta viene recuperata tramite lastErrorWrapper.InnerException e viene assegnata alla variabile lastError. Le informazioni di traccia del tipo, del messaggio e dello stack vengono recuperate da lastError e archiviate in tre variabili di stringa.

Viene quindi creato un MailMessage oggetto denominato mm . Il corpo del messaggio di posta elettronica è formattato in formato HTML e visualizza l'URL della pagina richiesta, il nome dell'utente attualmente connesso e le informazioni sull'eccezione (tipo, messaggio e traccia dello stack). Uno degli elementi più interessanti della HttpException classe è che è possibile generare il codice HTML usato per creare lo schermo giallo dell'eccezione (YSOD) chiamando il metodo GetHtmlErrorMessage. Questo metodo viene usato qui per recuperare il markup Dettagli eccezione YSOD e aggiungerlo al messaggio di posta elettronica come allegato. Una parola di attenzione: se l'eccezione che ha attivato l'evento Error è stata un'eccezione basata su HTTP ,ad esempio una richiesta per una pagina non esistente, il GetHtmlErrorMessage metodo restituirà null.

Il passaggio finale consiste nell'inviare l'oggetto MailMessage. Questa operazione viene eseguita creando un nuovo SmtpClient metodo e chiamando il Send relativo metodo.

Nota

Prima di usare questo codice nell'applicazione Web, è necessario modificare i valori nelle ToAddress costanti e FromAddress da support@example.com a qualsiasi indirizzo di posta elettronica da cui inviare e originare il messaggio di posta elettronica di notifica degli errori. Sarà anche necessario specificare le impostazioni del server SMTP nella <system.net> sezione in Web.config. Consultare il provider host Web per determinare le impostazioni del server SMTP da utilizzare.

Con questo codice sul posto ogni volta che si verifica un errore, lo sviluppatore invia un messaggio di posta elettronica che riepiloga l'errore e include YSOD. Nell'esercitazione precedente è stato illustrato un errore di runtime visitando Genre.aspx e passando un valore non valido ID tramite la stringa di query, ad esempio Genre.aspx?ID=foo. Visitare la pagina con il Global.asax file sul posto produce la stessa esperienza utente dell'esercitazione precedente: nell'ambiente di sviluppo si continuerà a visualizzare i dettagli dell'eccezione Schermata gialla di morte, mentre nell'ambiente di produzione verrà visualizzata la pagina di errore personalizzata. Oltre a questo comportamento esistente, lo sviluppatore invia un messaggio di posta elettronica.

La figura 2 mostra il messaggio di posta elettronica ricevuto quando si visita Genre.aspx?ID=foo. Il corpo del messaggio di posta elettronica riepiloga le informazioni sull'eccezione, mentre l'allegato YSOD.htm visualizza il contenuto visualizzato in Dettagli eccezione YSOD (vedere la figura 3).

Screenshot del messaggio di posta elettronica ricevuto con le informazioni sull'eccezione.

Figura 2: Lo sviluppatore invia una notifica di Email ogni volta che si verifica un'eccezione non gestita
(Fare clic per visualizzare l'immagine a dimensione intera)

Screenshot della notifica tramite posta elettronica ricevuta dallo sviluppatore quando si verifica un'eccezione non gestita.

Figura 3: La notifica di Email include i dettagli dell'eccezione YSOD come allegato
(Fare clic per visualizzare l'immagine a dimensione intera)

Informazioni sull'uso della pagina di errore personalizzata?

Questa esercitazione ha illustrato come usare Global.asax e il Application_Error gestore eventi per eseguire il codice quando si verifica un'eccezione non gestita. In particolare, questo gestore eventi è stato usato per notificare a uno sviluppatore un errore; È possibile estenderlo anche per registrare i dettagli dell'errore in un database. La presenza del Application_Error gestore eventi non influisce sull'esperienza dell'utente finale. Viene comunque visualizzata la pagina degli errori configurata, ad esempio Dettagli errore YSOD, Errore di runtime YSOD o pagina di errore personalizzata.

È naturale chiedersi se il file e Application_Error l'evento Global.asax sono necessari quando si usa una pagina di errore personalizzata. Quando si verifica un errore, viene visualizzata la pagina di errore personalizzata, quindi perché non è possibile inserire il codice per inviare una notifica allo sviluppatore e registrare i dettagli dell'errore nella classe code-behind della pagina di errore personalizzata? Anche se è certamente possibile aggiungere codice alla classe code-behind della pagina di errore personalizzata, non si ha accesso ai dettagli dell'eccezione che ha attivato l'evento Error quando si usa la tecnica illustrata nell'esercitazione precedente. La chiamata al GetLastError metodo dalla pagina di errore personalizzata restituisce Nothing.

Il motivo di questo comportamento è dovuto al raggiungimento della pagina di errore personalizzata tramite un reindirizzamento. Quando un'eccezione non gestita raggiunge il runtime di ASP.NET il motore di ASP.NET genera il relativo Error evento (che esegue il gestore eventi) e reindirizza l'utente Application_Error alla pagina di errore personalizzata eseguendo un Response.Redirect(customErrorPageUrl)oggetto . Il Response.Redirect metodo invia una risposta al client con un codice di stato HTTP 302, indicando al browser di richiedere un nuovo URL, ovvero la pagina di errore personalizzata. Il browser richiede quindi automaticamente questa nuova pagina. È possibile indicare che la pagina di errore personalizzata è stata richiesta separatamente dalla pagina in cui è stato generato l'errore perché la barra degli indirizzi del browser cambia nell'URL della pagina di errore personalizzata (vedere la figura 4).

Screenshot del browser che viene reindirizzato alla pagina di errore personalizzata U R L quando si verifica un errore.

Figura 4: Quando si verifica un errore, il browser viene reindirizzato all'URL della pagina di errore personalizzata
(Fare clic per visualizzare l'immagine a dimensione intera)

L'effetto netto è che la richiesta in cui si è verificata l'eccezione non gestita termina quando il server risponde con il reindirizzamento HTTP 302. La richiesta successiva alla pagina di errore personalizzata è una nuova richiesta; a questo punto il motore di ASP.NET ha rimosso le informazioni sull'errore e, inoltre, non ha modo di associare l'eccezione non gestita nella richiesta precedente alla nuova richiesta per la pagina di errore personalizzata. Questo è il motivo per cui GetLastError viene restituito null quando viene chiamato dalla pagina di errore personalizzata.

Tuttavia, è possibile che la pagina di errore personalizzata venga eseguita durante la stessa richiesta che ha causato l'errore. Il Server.Transfer(url) metodo trasferisce l'esecuzione all'URL specificato e la elabora all'interno della stessa richiesta. È possibile spostare il codice nel Application_Error gestore eventi nella classe code-behind della pagina di errore personalizzata, sostituendolo con Global.asax il codice seguente:

Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
    ' Get the error details
    Dim lastErrorWrapper As HttpException = _
        CType(Server.GetLastError(), HttpException)

    If lastErrorWrapper.GetHttpCode() = 404 Then
        Server.Transfer("~/ErrorPages/404.aspx")
    Else
        Server.Transfer("~/ErrorPages/Oops.aspx")
    End If
End Sub

Ora, quando si verifica un'eccezione non gestita, il gestore eventi trasferisce il Application_Error controllo alla pagina di errore personalizzata appropriata in base al codice di stato HTTP. Poiché il controllo è stato trasferito, la pagina di errore personalizzata ha accesso alle informazioni sulle eccezioni non gestite tramite Server.GetLastError e può inviare una notifica a uno sviluppatore dell'errore e registrarne i dettagli. La Server.Transfer chiamata impedisce al motore di ASP.NET di reindirizzare l'utente alla pagina di errore personalizzata. Al contrario, il contenuto della pagina di errore personalizzata viene restituito come risposta alla pagina che ha generato l'errore.

Riepilogo

Quando si verifica un'eccezione non gestita in un'applicazione Web ASP.NET il runtime di ASP.NET genera l'evento Error e visualizza la pagina di errore configurata. È possibile inviare una notifica allo sviluppatore dell'errore, registrarne i dettagli o elaborarlo in altro modo, creando un gestore eventi per l'evento Error. Esistono due modi per creare un gestore eventi per HttpApplication eventi come Error: nel Global.asax file o da un modulo HTTP. Questa esercitazione ha illustrato come creare un Error gestore eventi nel Global.asax file che notifica agli sviluppatori un errore tramite un messaggio di posta elettronica.

La creazione di un Error gestore eventi è utile se è necessario elaborare eccezioni non gestite in modo univoco o personalizzato. Tuttavia, la creazione di un gestore eventi personalizzato Error per registrare l'eccezione o per notificare a uno sviluppatore non è l'uso più efficiente del tempo perché esiste già una libreria di registrazione degli errori gratuita e facile da usare che può essere configurata in pochi minuti. Le due esercitazioni successive esaminano due librerie di questo tipo.

Buon programmatori!

Altre informazioni

Per altre informazioni sugli argomenti descritti in questa esercitazione, vedere le risorse seguenti:

IndietroAvanti