Traitement des événements en arrière-plan de l'intervenant

J'ai eu des problèmes avec la gestion des événements dans les threads d'arrière-plan. Toute la documentation que j'ai rencontrée me fait croire que lorsqu'un gestionnaire d'événement DoWork lève une exception, cette exception doit être traitée dans le gestionnaire RunWorkerCompleted et cette exception sera disponible dans la propriété Error de RunWorkerCompletedEventArgs. C'est très bien, mais pendant le débogage, je vois toujours une exception non gérée par un message de code utilisateur. Cela me fait croire qu'il y a un problème avec mon approche.Traitement des événements en arrière-plan de l'intervenant

Quelles mesures dois-je prendre pour résoudre ce problème?

Cordialement, Jonathan

Source

2009-03-20 jon37

Je l'ai vu ce comportement avant, et j'ai eu autour de lui en décorant le gestionnaire DoWork avec l'attribut System.Diagnostics.DebuggerNonUserCode:

[System.Diagnostics.DebuggerNonUserCode] 
void bw_DoWork(object sender, DoWorkEventArgs e) 
{ ... }

Remarque que vous ne verrez cela que si vous utilisez le débogueur; même sans l'attribut, tout est comme il se doit en courant depuis le shell.

J'ai encore regardé ceci, et je ne vois toujours pas pourquoi vous devriez faire cela. Je l'appelle un défaut de débogage.

Source

2009-03-20 00:47:24

Pourquoi avez-vous besoin de faire cela? Parce que c'est comme ça que fonctionne BackgroundWorker. Il est beaucoup plus facile de gérer l'erreur dans le thread appelant que dans le thread de travail. Mais lors du débogage, l'inverse est vrai puisque vous avez accès à toutes les variables locales. – Samuel

Je ne pense pas que "c'est comme cela que fonctionne BackgroundWorker" est une réponse satisfaisante. Il semble que vous voyiez toutes les exceptions comme indicatives d'erreurs de codage - c'est vrai seulement parfois. Si je voulais que le débogueur casse une exception gérée, j'ouvre les exceptions de la première chance ou définissez un point d'arrêt. –

Votre approche est correcte. Appuyez simplement sur continuer sur le message et continuez. En cas de doute, testez-le en dehors d'une session de débogage.

Source

2009-03-20 00:32:14 Ray

J'ai déjà eu ce problème auparavant. L'erreur e.Error n'est définie que si vous ne l'utilisez pas en mode débogage. Si vous exécutez Debug, l'exécution s'arrête à l'emplacement de l'exception. Cependant, exécutez le même programme en mode Non déboguage (dans VS Déboguer -> Démarrer sans débogage ou Ctrl + F5) et la méchante boîte de dialogue NE SERA PAS affichée, et e.Error sera l'exception. Je ne sais pas pourquoi, mais comment ça marche ....

Source

2009-03-20 00:35:03 BFree

Traitement des événements en arrière-plan de l'intervenant

Répondre

Questions connexes