Informar al usuario final de las excepciones en Winforms-MVP y WPF-MVVM

Question

Durante medio año de Winforms-MVP diseñé la siguiente estrategia de manejo de excepciones. Tengo una clase de presentación abstracta base con varios métodos de ejecución que toman un delegado como parámetro de entrada (las firmas varían). La interacción entre la Vista y el Presentador se realiza a través de eventos (entrada) definidos en IView y al establecer propiedades públicas (salida) o métodos de llamadas definidos en la IView también e implementados por la Vista. Cada controlador de eventos en el presentador llama a uno de los métodos de ejecución proporcionándole una realización concreta.

En el método de ejecución tengo varios bloques catch para excepciones muy definidas que pueden ocurrir (principalmente debido a algunos problemas en los componentes externos que se usan ampliamente). Cada una de estas excepciones detiene la ejecución de la operación actual, se registra y se muestra al usuario con una explicación significativa llamando a los métodos de View.

No hace mucho tiempo (de hecho MUY no hace mucho tiempo) Empecé a aprender WPF-MVVM, que a primera vista parece tener mucho en común con MVP. Estaba buscando algún consejo útil sobre la estrategia de manejo de excepciones allí (principalmente informar al usuario sobre los problemas), pero estas preguntas son difíciles de buscar en general, es decir, se dice mucho, pero principalmente en principio. He encontrado más de 20 ejemplos de "manejo" de excepciones no controladas en la aplicación.xaml.cs, todo es muy lindo, pero díganlo con sinceridad: si conoce las excepciones exactas que pueden bloquear su aplicación, ¿no las manejará? un poco antes (incluso si se verá obligado a cerrar su aplicación)? No soy fan de atrapar todas las excepciones posibles. Muchas de las excepciones causadas por los problemas de red, la falta de disponibilidad temporal de la base de datos, etc. deben manejarse sin cerrar la aplicación sin iconos de error que den al usuario común la oportunidad de repetir su solicitud.

Así que, como experimento, probé casi lo mismo que describí anteriormente: he creado eventos en ViewModel para la transición de excepciones y la vista suscrita. Pero, francamente, de esta manera me da escalofríos.

(Fue un discurso muy largo, lo sé) La pregunta: ¿cómo se manejan las excepciones en lo que se refiere a informar al usuario cuando se usa MVVM? No, no estoy interesado en la validación de datos solo por ahora. Cualquier crítica y/o consejo sobre MVP también es bienvenido.

Answer 1

Tenemos un par de estrategias diferentes para diferentes tipos de condiciones de error en nuestras aplicaciones Wpf.

Para los errores anticipados que el código puede manejar y proceder sin notificar al usuario, hacemos los bloques normales de Prueba de captura.

Para errores anticipados pero que provocan un error desde el punto de vista de los usuarios, exponemos una colección de notificaciones en nuestros ViewModels, enlazados a un ItemsControl en nuestro View que está modelado de manera similar a las barras de notificación en Firefox/IE/Chrome.Cada notificación tiene una propiedad de duración de espectáculo (la colección de notificaciones es autoajustable usando un temporizador de despachador) y un botón de cierre en la vista, de modo que pueden aparecer durante un período de tiempo específico o pueden ser cerradas explícitamente por el usuario. Lo bueno de este modelo es que puede usarse para mensajes de finalización, advertencias y excepciones, y también para algunas condiciones que podrían no manifestarse como una excepción, pero que siguen siendo condiciones de error desde el punto de vista de los usuarios. Las notificaciones suelen ser un buen reemplazo para el cuadro de mensaje, ya que no interrumpen el flujo de trabajo de los usuarios.

Para los errores que no anticipamos utilizamos Red Gate SmartAssembly para capturar todos los detalles para que los usuarios puedan enviarlos a nuestro soporte para el análisis. Nuestra opinión es que capturar y continuar su aplicación después de excepciones que no ha anticipado es una estrategia muy arriesgada: la pila de una excepción inesperada no se desenrolla y su aplicación quedará en un estado inconsistente después del error (lo que podría generar cualquier cosa desde una interfaz de usuario extraña a datos corruptos) y podría haber efectos secundarios que son imposibles de predecir. No es una gran experiencia de usuario tener un bloqueo de la aplicación, pero es una experiencia significativamente peor tenerla dañada debido a un estado imprevisto causado por un error que la aplicación ignoró. Nuestra estrategia es capturar la mayor cantidad de detalles sobre el choque para que el usuario sepa que nos tomamos en serio el problema y lo solucionaremos/atraparemos en una actualización futura, en lugar de continuar y encaminarnos hacia problemas potencialmente peores.

Answer 2

Acepto, dejando el manejo de excepciones en su aplicación.xaml.cs no es bueno, ¡porque es demasiado tarde!

Para las operaciones donde una posible excepción es relativamente alta (manejo de archivos, IO de red), asegúrese de detectar activamente las excepciones. Expongo esto a la vista de una de dos maneras:

1. Para los errores que indican algún problema de larga duración, problemas de red, por ejemplo, que exponen una poperty 'ErrorState'
2. Para problemas transitorios, archivo no encontrado por ejemplo, exponer un evento.