En fait, il ne semble pas y avoir beaucoup d'explications à ce sujet apparemment, mais les codes de sortie sont censés être utilisés pour donner une indication sur la façon dont le thread est sorti, cela 0tend à signifier qu'il est sorti en toute sécurité alors que tout le reste tend à signifier qu'il n'a pas ne quittez pas comme prévu. Mais alors ce code de sortie peut être défini dans le code par vous-même pour complètement ignorer cela.
Le lien plus approchante être utile pour plus d' informations est ce
Citation du lien ci-dessus:
Quelle que soit la méthode de sortie, l'entier que vous renvoyez de votre processus ou thread doit être des valeurs comprises entre 0 et 255 (8 bits). Une valeur zéro indique le succès, tandis qu'une valeur différente de zéro indique un échec. Bien que vous puissiez tenter de renvoyer n'importe quelle valeur entière en tant que code de sortie, seul l'octet le plus bas de l'entier est renvoyé par votre processus ou thread dans le cadre d'un code de sortie. Les octets d'ordre supérieur sont utilisés par le système d'exploitation pour transmettre des informations spéciales sur le processus. Le code de sortie est très utile dans les programmes batch / shell qui exécutent conditionnellement d'autres programmes en fonction du succès ou de l'échec de l'un.
À partir de la documentation de GetEXitCodeThread
Important La fonction GetExitCodeThread renvoie un code d'erreur valide défini par l'application uniquement après la fin du thread. Par conséquent, une application ne doit pas utiliser STILL_ACTIVE (259) comme code d'erreur. Si un thread renvoie STILL_ACTIVE (259) comme code d'erreur, les applications qui testent cette valeur peuvent l'interpréter comme signifiant que le thread est toujours en cours d'exécution et continuer à tester l'achèvement du thread après la fin du thread, ce qui pourrait mettre le thread application dans une boucle infinie.
Ma compréhension de tout cela est que le code de sortie n'a pas tellement d'importance si vous utilisez des threads dans votre propre application pour votre propre application. L'exception à cela est peut-être si vous exécutez simultanément deux threads qui ont une dépendance l'un sur l'autre. S'il est nécessaire qu'une source externe lise ce code d'erreur, vous pouvez le configurer pour informer les autres applications de l'état de votre thread.
RunAsync().Wait();static void Main(string[] args) { var t = new Task<object>(() => SomeOp(2)); t.Start(); t.Wait(); }Le fait est que les tâches sont exécutées par les threads du pool de threads et, en fonction de l'heuristique du pool de threads, il se peut qu'il ne termine pas le thread même une fois votre tâche terminée. Le thread revient simplement au pool de threads en attente d'être affecté à la tâche suivante. Et c'est pourquoi le code de sortie STILL_ACTIVE (259) semble si intuitif ici.Comme Sayse l'a mentionné, le code de sortie
259 (0x103)a une signification particulière, dans ce cas, le processus en cours de débogage est toujours en cours d'exécution.J'ai beaucoup vu cela avec le débogage des services Web, car le thread continue de fonctionner après l'exécution de chaque appel de service Web (car il écoute toujours d'autres appels).
la source
ce qui m'est arrivé, c'est que j'ai plusieurs projets dans ma solution. Je voulais déboguer le projet 1, cependant, le projet 2 a été défini comme projet de départ par défaut. J'ai corrigé cela en faisant un clic droit sur le projet et sélectionnez "Définir comme projet de démarrage", puis exécuter le débogage est très bien.
la source