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.