En .NET 2.0 y WinForms había una forma que ahora ya no es del todo válida en WPF ya que han desaparecido el método Application.SetUnhandledExceptionMode y el evento Application.ThreadException, en su lugar tenemos Application.DispatcherUnhandledException:

<Application x:Class="KiosimWPF.App"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    StartupUri="Window1.xaml" 

    DispatcherUnhandledException="App_DispatcherUnhandledException">

    <Application.Resources>

    </Application.Resources>

</Application>

Luego en el handler del evento podemos evitar que la excepción tumbe la aplicación:

Mas...

Buff... cuanto tiempo desde mi último post, entre estudiar y la medio-gripe que arrastro desde hace unas semanas no tengo ganas tiempo de nada :P

Un tema que siempre me ha parecido que se deja un poco olvidado a la hora de desarrollar una aplicación es el tema de las excepciones, su flujo, su registro y como afectan al diseño y modularidad de la aplicación.

Una excepción, es un error en el flujo lógico ideal de nuestra aplicación causado por una condición inusual. Ante un error de este tipo, debemos actuar para corregirlo y/ó recuperar un estado consistente ó registrarlo en algún lugar(archivo log, EventLog, ..etc..) donde el administrador pueda ver que ha sucedido y tomar medidas. Esto es algo bien sabido por todos, pero el problema viene cuando hay que decidir que hacer con las excepciones que no podemos solucionar y como registrar de forma descriptiva el problema para poder solventarlo.

Mas...