Le applicazioni sviluppate con Silverlight per Windows Phone 7 sono processi basati sul CLR e quindi sui medesimi meccanismi delle applicazioni Windows o Web. Le eccezioni nel mondo .NET sono interruzioni dello stack in esecuzione che, se non gestite e previste con un try/catch, vengono rilanciate lungo tutto lo stack delle chiamate fino ad arrivare al motore principale dell'applicazione.
Prevedere nel codice queste eccezioni, soprattutto laddove si eseguono operazioni che potenzialmente possono dare problemi, come IO o networking, è doveroso. Mirare, ad esempio, la gestione delle eccezioni tramite l'evento ***Completed della classe WebClient o di un proxy WebService permette infatti di avvisare l'utente o di reagire automaticamente a situazioni che possono essere previste, prima tra tutte l'instabilità della connessione internet.
Non sempre si è riesce a coprire tutti i casi o a proteggere tutto il codice, perciò in queste situazioni l'applicazione va di fatto in crash, terminando. Per generalizzare e gestire gli errori viene quindi in aiuto l'evento UnhandledException della classe Application che è possibile trovare già intercettato nel file App.xaml.cs del template di Visual Studio. Nel codice predefinito si trova la chiamata a Debugger.Break per bloccare il debugger in caso si stia testando l'applicazione per poter analizzare l'errore. Di maggiore utilità è invece la proprietà Handled dell'argomento, che permette di inibire l'errore proseguendo il normale ciclo di vita, come mostrato nell'esempio:
private void Application_UnhandledException(object sender, ApplicationUnhandledExceptionEventArgs e) { if (System.Diagnostics.Debugger.IsAttached) { // An unhandled exception has occurred; break into the debugger System.Diagnostics.Debugger.Break(); } // Inibisco l'errore e.Handled = true; // Messaggeo user friendly Deployment.Current.Dispatcher.BeginInvoke(() => { MessageBox.Show("Errore imprevisto: " + e.ExceptionObject.Message); }); }
Nel codice precedente si mostra anche un errore generico all'utente. Va inoltre sottolineato che questo evento viene chiamato anche per eccezioni lanciate da thread secondari (thread pool o personalizzati) e per questo motivo si invoca la message box tramite il Dispatcher. Infine questo evento non mette al riparo dal superamento della memoria che il dispositivo dispone, il quale causa inesorabilmente il crash dell'applicazione.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Utilizzare parametri a livello di controller nel routing di ASP.NET Core
Introduzione alla security con GitHub
Utilizzare l'attributo autofill del CSS
Usare il versioning con i controller di ASP.NET Core Web API
Effettuare delete massive con Entity Framework Core 7
Creare form tipizzati con Angular
Utilizzare la libreria EntityFrameworkCore.Exceptions per gestire le eccezioni di Entity Framework Core in modo tipizzato
Sfruttare i tag nell'output cache di ASP.NET Core 7
Usare Refit e Polly in Blazor per creare client affidabili e fortemente tipizzati
Test reporting in un workflow di GitHub
Ottimizzare il codice JavaScript utilizzando WeakMap e WeakSet
Utilizzare i nuovi piani dedicati di Azure Container Apps