Voir les modifications ci-dessous pour reproduire le comportement que je décris dans ce problème.
Le programme suivant ne finira jamais, car le rendement pour cet exemple trivial, je pourrais évidemment utiliser Y a-t-il un moyen de produire ce comportement? EDIT: OK, le problème est différent de celui que j'ai pensé d'abord. Le programme ci-dessus ne se termine pas et le pourquoi est-ce que le Edit # 2:
À partir d'une invite de commande, le programme exécute la même chose dans les deux cas. Dans Visual Studio Enterprise 2015, Update 2, que je compile dans le débogage ou la libération, le comportement ci-dessus est ce que je vois. Avec le Edit # 3: Fixé
Pour moi, la question a été résolue par la réponse de @martinBrown. Lorsque je décocher l'option de Visual Studio sous Débogou> Options> Débogage> Général> "Détendez la pile d'appel sur des exceptions non gérées" Ce problème disparaît. Lorsque je vérifie à nouveau la boîte, le problème revient. renvoie construction dans c # appelle le getstrings () < / code> méthode indéfiniment lorsqu'une exception est lancée. retour énumérable.empty ienumerable . . foreach se comporte comme une boucle infinie. Le programme ci-dessous se termine, et l'exception est affichée sur la console. essaie ... attrape Block faire une différence dans ce cas? Cela me semble très étrange. Merci à @andrewkilburn pour sa réponse déjà pour me faire remarquer cela. ESSAYER ... CATCH , le programme se termine par une exception et sans qu'il Visual Studio ne ferme jamais le programme.
4 Réponses :
class Program {
static void Main(string[] args) {
try {
foreach (var item in GetStrings()) {
Console.WriteLine();
}
}
catch (Exception ex) {
}
}
private static IEnumerable<string> GetStrings() {
// REPEATEDLY throws this exception
throw new Exception();
yield break;
}
}
Putting it in a try catch causes it to break out and do whatever you want
Malheureusement, cela ne fonctionnera pas car l'exception n'est pas du tout jetée dans la méthode principale .
Ceci est intéressant ... mettre l'essai attraper rend le programme se comporter différemment. Sans le ESSAYER ... CATCH Le programme se termine-t-il pour vous?
@Johncarpenter mines de la même manière, ça ne finit pas. L'exception continue de se lancer, mais cela ne va pas autour du
Le programme suivant ne finira jamais
c'est faux. Le programme va se terminer assez rapidement.
Parce que la construction de rendement de rendement dans C # appelle la méthode
getstrings () indéfiniment lorsqu'une exception est lancée.Ceci est faux. Il ne fait pas cela du tout.
Je m'attendrais à ce que l'exception soit lancée une fois, alors la méthode s'arrête d'être appelée et jette l'exception dans la méthode "consommant" le
ienumerable . .C'est exactement ce que fait se produit.
Y a-t-il un moyen de produire ce comportement?
Utilisez le code que vous avez déjà fourni.
Eh bien, il s'est avéré de ne pas être. Apparemment, le comportement était différent au sein de Visual Studio. Ou au moins apparu différents. :)
Extrêmement inutile
Le comportement étant vu ici n'est pas une faute dans le code; C'est plutôt un effet secondaire du débogueur Visual Studio. Cela peut être résolu en éteignant la pile déroulant dans Visual Studio. Essayez d'aller dans les options de studio Visual Débogage / général et décochez «Détendez la pile d'appels sur des exceptions non gérées». Puis exécutez le code à nouveau.
Que se passe-t-il, c'est que lorsque votre code frappe une exception entièrement non fabriquée, Visual Studio se déroule de la pile d'appel à juste avant la ligne de votre code qui a provoqué l'exception. Cela le fait pour que vous puissiez modifier le code et continuer à exécuter avec le code modifié.
Le problème vu ici ressemble à une boucle infinie car lorsque vous redémarrez l'exécution dans le débogueur, la ligne suivante à exécuter est celle qui vient de provoquer une exception. En dehors du débogueur, la pile d'appels serait complètement déroulée sur une exception non heurtée et ne causerait donc pas la même boucle que vous obtenez dans le débogueur.
Cette fonction de déroulement de la pile peut être désactivée dans les paramètres, il est activé par défaut. La désactivation toutefois, vous arrêterez-vous de pouvoir éditer le code et de continuer sans vous dérouler de la pile. Ceci est toutefois assez facile à faire dans la fenêtre de la pile d'appels ou en sélectionnant simplement «Activer l'édition» de l'assistant d'exception.
Cela corrige le problème. Toute explication sur pourquoi?
Malheureusement, ma connaissance de ce que cela fait réellement est un peu limité. Faites-moi savoir si jamais vous le découvrez.
@Johncarpenter ici est décrit la fonctionnalité. (Vous pouvez trouver une description dans Commentaires)
@Matteoumili j'ai rempli la réponse un peu en suivant une lecture sur le sujet.
Est-ce que cela est parti pour vs 2017? @Martinbrown
@Mike, je n'ai pas eu la possibilité d'utiliser 2017, alors ne pouviez pas commenter.
@Mike Il apparaît, oui, il est parti dans VS2017. :( Voir le commentaire de Hans Passant sur cette question: Stackoverflow.com/Questtions/43126140/...
Unhandled Exception: System.Exception: EnumerableCount: 1
at {insert stack trace here}
Je l'ai essayé et ça ne jette qu'une seule fois. Dans le cas de l'emballage
foreach avecessayer de capter une exception a été apprécié uniquement une seule fois et le programme quitte. Est-ce que je l'ai bien compris?Hmmm, je ne vois pas ce comportement. Laissez-moi vérifier à nouveau pour être sûr. Le comportement que je constate est que l'exception est jetée, et elle est attrapée dans les coulisses et la boucle
foreach se comporte comme une boucle infinie.@Szer Voir mon édition, le
ESSAYER ...CATCH Les blocs semblent faire la différence de savoir si la boucle de Foreach agit comme une boucle infinie. Est ce que cela à un sens pour toi?Je ne peux pas reproduire le comportement "en boucle infinie". Sans
ESSAYEZ CATTER Programme s'est écrasé dès que l'exception a été lancée.Êtes-vous débogué cela dans Visual Studio? Quelle version utilisez-vous? J'ai vu des occasions étranges où Visual Studio ne parvient pas à passer à autre chose après avoir montré une exception qui apparaît que l'exception est lancée plus d'une fois quand elle n'est pas. Pas sûr que les circonstances exactes qui le causent cependant.
@Szer Si vous mettez un point de pause et suivez-le, une fois que cela frappe l'exception, il ne cessera pas de le jeter, il ne boucle pas. Cela continue de le jeter. Marquer ma réponse comme réponse choisie si correct s'il vous plaît
@MartinBrown J'utilise Visual Studio Enterprise 2015, compilation avec débogage "Toute CPU". Lorsque je clique sur Aide> À propos de Microsoft Visual Studio, je vois que la version est "Version 14.0.25123.00 Mise à jour 2"
IM Utilisation de VS2015 PRO Mise à jour 2 avec débogage AnyCPU sur X64 Win7. Essayez Ce violon. Déchargez le trykatch et vous verrez c'est bien tout va bien
@Szer je pourrais poster une vidéo ou quelque chose, mais mon programme n'est vraiment pas fini sans essayer ... Catch. Je suis sur X64 Windows 10
@Johncarpenter Avez-vous essayé de l'exécuter en dehors de Visual Studio?
@Szer Notez également que la pause de rendement
; est important. Votre violon n'a pas que dans la méthodegetstrings () . SansCause de rendement; La méthode s'exécute comme on peut s'y attendre.@MartinBrown Oui, il se comporte comme on m'attendrait en dehors de Visual Studio. Maintenant que cela semble être un problème de studio visuel, existe-t-il un meilleur endroit que pour la question?
J'ai exactement la même version que vous, exactement le même système d'exploitation que. S'écrase comme une tonne de briques sur n'importe quel gigue et toute cible-cadre et n'importe laquelle des moteurs de débogage disponibles. Vous aurez besoin d'obtenir votre machine.
Basé sur votre dernier commentaire, il semble que le comportement que vous voyez est causé par le débogueur de Visual Studio qui avale l'exception non gérée (version w / o try / attraper)? Est-ce que je l'interpréte correctement (éditer n ° 2)? Je ne suis même pas sûr qu'il existe un tel réglage dans VS qui le ferait, mais peut-être que cela aiderait ensuite à publier une capture d'écran de vos paramètres de débogage VS.
N / M, je vois que vous avez accepté une réponse avec ce que je pensais.