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
Ottenere il contenuto di una cartella FTP con la libreria FluentFTP
Usare le variabili per personalizzare gli stili CSS
Gestire liste di tipi semplici con Entity Framework Core
Esportare ed analizzare le issue di GitHub con la CLI e GraphQL
Eseguire query manipolando le liste contenute in un oggetto mappato verso una colonna JSON
Personalizzare l'errore del rate limiting middleware in ASP.NET Core
Specificare il versioning nel path degli URL in ASP.NET Web API
Copiare automaticamente le secret tra più repository di GitHub
Utilizzare politiche di resiliency con Azure Container App
Filtrare e rimuovere gli elementi dalla cache del browser tramite le API JavaScript
Load test di ASP.NET Core con k6
Modificare i metadati nell'head dell'HTML di una Blazor Web App