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
Miglioramenti nelle performance di Angular 16
Short-circuiting della Pipeline in ASP.NET Core
Disabilitare automaticamente un workflow di GitHub
Utilizzare la session affinity con Azure Container Apps
Generare file PDF da Blazor WebAssembly con iText
Reactive form tipizzati con modellazione del FormBuilder in Angular
Supportare il sorting di dati tabellari in Blazor con QuickGrid
Paginare i risultati con QuickGrid in Blazor
Specificare il versioning nel path degli URL in ASP.NET Web API
Utilizzare i primary constructor in C#
Come EF 8 ha ottimizzato le query che usano il metodo Contains
Sfruttare lo streaming di una chiamata Http da Blazor
I più letti di oggi
- Miglioramenti nelle performance di Angular 16
- Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
- HTML5 con CSS e JavaScript
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- Ottimizzazione dei block template in Angular 17
- Disabilitare automaticamente un workflow di GitHub (parte 2)