Si la gestion des exceptions doit être centralisée, la conception des composants WinForm est-elle incorrecte?

Question

Ou toute autre conception qui a les widgets gui comme étant le premier port d'escale où une exception non gérée va tuer l'application? Nous voulons tous un principal: "attraper tout" pour des raisons d'économie de visage (bien que dans la plupart des cas cela ne devrait pas avoir de fonction "continue") mais il est impossible d'en implémenter facilement un avec des widgets gui qui sont le premier port d'appel. Est-ce que cette conception est défectueuse ou est-ce que je manque un truc quelque part? Je demande cela parce que je lisais un article par le concepteur de la langue et il a déclaré que la gestion des exceptions devrait être centralisée et la première chose qui m'est apparue dans le mien était le mécanisme des événements WinForm où cela devient difficile. L'équipe WinForm/GUI était-elle à l'écoute, ou était-il trop tard à ce moment-là?

Answer 1

Vous pouvez mettre un try/catch autour Application.Run, et gérer Application.ThreadException. Dans les gestionnaires, vous pouvez enregistrer l'exception et quitter. Mis à part ce qui précède, je mets généralement un gestionnaire d'exception autour de tous les appels au Business Tier (et tous les accès aux ressources externes dans le niveau client, par exemple l'exportation vers un fichier) qui affichent une erreur mais ne quittent pas le application.

Answer 2

Connaissez-vous Application.ThreadException? Je ne dis pas que c'est nécessairement la meilleure réponse, mais c'est au moins une réponse ...