Quel est le meilleur moyen de collecter des données sur les accidents?

Je suis donc persuadé de vouloir collecter automatiquement les données d’un programme, c’est-à-dire d’afficher une boîte de dialog demandant à l’utilisateur d’envoyer le rapport en cas de problème.

Je travaille dans MS Visual Studio C #.

D’un sharepoint vue de la mise en œuvre, est-il judicieux de placer une boucle try / catch dans mon fichier principal program.cs, autour de l’emplacement d’exécution de l’application? Comme ça:

try { Application.Run(new myMainForm()); } catch (Exception ex) { //the code to build the report I want to send and to //pop up the Problem Report form and ask the user to send } 

ou est-il judicieux de mettre des boucles try / catch dans des parties du code pour capturer des types d’exception plus spécifiques? (Je ne pense pas qu’il s’agisse d’une nouvelle application, et la mise en place de captures d’exception plus spécifiques signifie que j’ai une idée de ce qui va mal se passer … ce n’est pas le cas, raison pour laquelle ce qui précède me semble logique .)

-Adeena

Je pense que vous avez raison, vous ne sauriez pas ce qui ne va pas, ce qui est le but.

Toutefois, vous pouvez également envisager d’append un gestionnaire à l’événement ThreadException .

Le code ci-dessus fonctionnera, mais il y aura des scénarios dans lesquels le multi-threading pourrait être un problème avec ce code, dans la mesure où tout le code de votre programme Windows Forms ne sera pas exécuté dans le thread principal de la boucle Application.Run.

Voici un exemple de code de l’article lié:

 [STAThread] static void Main() { System.Windows.Forms.Application.ThreadException += new ThreadExceptionEventHandler(ReportError); System.Windows.Forms.Application.Run(new MainForm()); } private static void ReportError(object sender, ThreadExceptionEventArgs e) { using (ReportErrorDialog errorDlg = new ReportErrorDialog(e.Exception)) { errorDlg.ShowDialog(); } } 

Plus de documentation sur MSDN .

Sur un point mineur, l’utilisation de l’événement ThreadException permet également à votre boucle de message principale de continuer à s’exécuter si l’exception n’est pas fatale (scénarios de tolérance de panne), alors que l’approche try / catch peut nécessiter le redémarrage de la boucle de message principale qui pourrait provoquer des effets secondaires.

Du sharepoint vue de la mise en œuvre, est-il judicieux de placer une boucle try / catch dans mon fichier principal program.cs, autour du lieu où l’application est exécutée?

Bien sûr et toujours.

Vous devez utiliser Try / Catch-Blocks partout où vous faites quelque chose de critique, cela peut déclencher une exception.

Par conséquent, vous ne pouvez pas vraiment vous en tenir à un modèle pour cela, car vous devriez maintenant savoir quand une exception sera levée. Sinon, ce sont des exceptions non gérées, qui permettent à votre programme de planter.

Mais il existe de nombreuses exceptions, qui ne doivent pas nécessairement arrêter complètement l’application, des exceptions, qui peuvent tout simplement être avalées, car elles sont attendues et ne nécessitent absolument pas l’arrêt de l’application. UnauthorizedAccessExceptions pour déplacer ou accéder à des données avec votre programme en est un exemple.

Vous devriez essayer de garder les blocs d’essai et de capture aussi petits que nécessaire, ainsi que de ne pas en utiliser trop, pour des raisons de performance.

Certains utilisent Try / Catch pour diriger l’exécution du programme. Cela devrait être entièrement évité dans la mesure du possible, car le fait de créer une exception est le tueur numéro 1.

Si l’ensemble de l’application est capturée, l’application se fermera en cas d’erreur.

En utilisant un essai et attraper chaque méthode est difficile à maintenir.

La meilleure pratique consiste à utiliser des captures d’essais spécifiques autour des unités de code qui généreront des types d’exception spécifiques tels que FormatException et laisseront la gestion des exceptions générales aux gestionnaires d’événements au niveau de l’application.

 try { //Code that could error here } catch (FormatException ex) { //Code to tell user of their error //all other errors will be handled //by the global error handler } 

L’expérience vous dira le type de problèmes qui pourraient survenir. Au fil du temps, vous remarquerez que votre application jette souvent des exceptions dites d’entrées-sorties autour de l’access aux fichiers afin que vous puissiez les récupérer ultérieurement et donner davantage d’informations à l’utilisateur.

Les gestionnaires globaux d’erreurs intercepteront tout le rest. Vous les utilisez en associant des gestionnaires d’événements aux deux événements System.Windows.Forms.Application.ThreadException ( voir MSDN ) et AppDomain.UnhandledException ( voir MSDN ).

Sachez que les exceptions de mémoire insuffisante et StackOverflowException peuvent ne pas être interceptées par une erreur de capture.

Si vous souhaitez obtenir automatiquement des traces de stack, Microsoft vous autorise à les envoyer via les services de rapport d’erreurs. Tout ce que vous avez à faire est de vous inscrire à un certificate numérique de VeriSign et de l’enregistrer (gratuitement) auprès de Microsoft.

Microsoft vous donne ensuite un identifiant pour vous permettre de télécharger les mini-dumps à partir d’un site Web, qui sont soumis lorsqu’un utilisateur clique sur “Envoyer un rapport d’erreur”.

Bien que les gens puissent cliquer sur “Ne pas envoyer”, il s’agit au moins d’une boîte de dialog Microsoft, voire d’une boîte de dialog que vous ne devez pas coder vous-même. Il fonctionnerait 24 heures sur 24, 7 jours sur 7, vous n’auriez pas à vous soucier de la disponibilité de votre serveur Web ET vous pouvez soumettre des informations sur la solution de contournement pour les utilisateurs ET vous pouvez fournir des mises à jour via Windows Update.

Des informations sur ce service se trouvent dans cet article ” Rapport d’erreurs Windows: Mise en route “.

La meilleure approche consiste à choisir les exceptions AppDomain.UnhandledException et Application.ThreadException dans la fonction principale de votre application. Cela vous permettra d’enregistrer toutes les exceptions non gérées dans votre application. Envelopper dans un bloc catch try ne prend pas tout.

si vous voulez juste capturer les plantages, ignorez toutes les erreurs et laissez DrWatson générer un minidump pour vous. Ensuite, vous pouvez regarder dans un débogueur (windbg est préféré pour les minidumps) et il vous montrera la ligne sur laquelle votre code a mal tourné, ainsi que tous les parameters, trace de stack et registres. Vous pouvez configurer Drwatson pour qu’il génère un vidage complet dans lequel vous aurez à effectuer un vidage de la mémoire complète.

Je ne recommanderais pas d’essayer / intercepter toute l’application à moins que vous ne vouliez que votre application ne se “bloque” jamais devant l’utilisateur. Elle sera toujours traitée et probablement ignorée car vous ne pouvez rien faire à l’exception de ce point.

Envoi du minidump à vous est une autre affaire cependant, voici un article , vous devrez faire quelques efforts pour le faire envoyer par e-mail / http / ftp / etc.