Où les exceptions devraient-elles être interceptées et traitées dans une application WPF?

Question

Nous avons l'exception attraper le code dans la plupart de nos gestionnaires d'événements etc, cela conduit à une logique très complexe, avec des drapeaux qui sont configurés pour dire s'il y a eu une exception pour ne pas faire l'étape suivante etc .. sight Je déplacerais tous les rapports d'exception/logging vers l'événement AppDomain.UnhandledException, mais d'après mon expérience avec WinForms, beaucoup d'exceptions seront perdues.

En cas d'exception, nous incluons également les détails de l'opération que l'utilisateur essayait de faire dans le message du journal.

Alors, quelles sont les expériences à la fois mauvaise et bonne à l'exploitation forestière exception/reporting/récupération dans les applications WCF? (J'adorerais dire que nous avions quelque chose comme le modèle MVVM (Model-View ViewModel) en cours d'utilisation, mais nous ne sommes pas et sommes loin d'être en mesure d'utiliser un design "propre" comme celui-là

Answer 1

Vous ne devriez jamais avoir à utiliser des drapeaux pour dire que des exceptions ont été gérées - ça sent mauvais.

Les exceptions se divisent en deux catégories:

• prévu (par exemple, la validation a échoué, les données ne peuvent pas être mises en base de données)
• inattendue

vos proches attendus doivent être manipulés assez rapidement, et connecté en fonction du type d'exception. Par exemple, si l'utilisateur saisissait des données rejetées par le code de validation dans la couche de gestion, j'attraperais l'exception et notifierais l'utilisateur, mais je ne l'enregistrerais pas - parce que c'était prévu et que je pouvais m'en occuper. D'autres peuvent être "attendus", mais vous ne pouvez pas y faire face - comme un appel WCF a échoué en raison d'un délai d'expiration ou d'un paquet de données surdimensionné. Cela vous devriez certainement vous connecter - vous pouvez même être en mesure de récupérer, donc une fois de plus il devrait être pris et traité. Notez l'absence de drapeaux - une exception est gérée ou continue à exploser. Si vous devez prendre une action que vous pouvez le faire, et réémettre alors l'exception de le laisser bouillonner plus loin - regard, toujours pas de drapeaux :)

Une autre approche que j'ai pris dans le passé lors du lancer (sur mesure) Les exceptions attendues dans une application ASP.NET sont de la marquer comme pouvant être gérée localement ou non. Cela signifie que lorsque l'aspx a détecté l'erreur (gestionnaire d'erreur générique dans une page de base dont tous les Apsx ont hérité), alors il savait s'il devait simplement l'afficher localement dans la page (après avoir fait une recherche de texte dans un fichier ressource). s'il devrait rediriger vers une page d'erreur. Cette approche était particulièrement utile lorsque vous faisiez un mélange de postbacks standard et de rappels ajax (peut-être pas particulièrement utile pour les applications WPF).

Pour les erreurs inattendues majeures, vous pouvez les détecter au niveau de l'application, here is a previous SO post about it. Deux autres messages associés peuvent être utiles: here et here. Une autre chose que je devrais mentionner est de s'assurer que votre journalisation des erreurs est relativement pare-balles - il n'y a rien de pire que votre processus de journalisation des exceptions jetant une exception, et perdant tous les détails précieux de ce bogue difficile que vous essayez de traquer cet utilisateur furieux.

Answer 2

Ce n'est pas spécifique à WPF, mais le meilleur endroit pour gérer les exceptions est de les gérer au moment où l'interaction de l'utilisateur avec le formulaire est convertie en un processus logique. C'est soit dans le codebehind ou dans une méthode de contrôleur. Ce n'est qu'à ce niveau que vous savez ce que l'utilisateur essaie de faire et quelles sont les mesures raisonnables à prendre en cas de situation exceptionnelle.

Bien sûr, si vous ne savez pas quelles exceptions peuvent être lancées, n'essayez pas de les gérer. Et ne vous occupez pas des exceptions dont vous ne pouvez rien faire.