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 le Cache API di JavaScript per salvare elementi nella cache del browser
Effettuare il binding di date in Blazor
Potenziare Azure AI Search con la ricerca vettoriale
Criptare la comunicazione con mTLS in Azure Container Apps
Registrare servizi multipli tramite chiavi in ASP.NET Core 8
Applicare il versioning ai nostri endpoint ASP.NET Core Minimal API
Ottenere il contenuto di una cartella FTP con la libreria FluentFTP
Usare una container image come runner di GitHub Actions
Workflow di continuous deployment tramite pull request label in GitHub
Usare Refit e Polly in Blazor per creare client affidabili e fortemente tipizzati
Usare lo spread operator con i collection initializer in C#
Short-circuiting della Pipeline in ASP.NET Core