Pourquoi mon application asp.net lance-t-elle ThreadAbortException ?

Question

question explicite.

Pourquoi cette chose bouillonne-t-elle dans mes tentatives même si tout va bien ?

Pourquoi apparaît-il dans mon journal des centaines de fois ?

Je sais que c'est une nouvelle question, mais si ce site veut obtenir un classement dans les recherches et attirer des nouveaux, nous devons leur poser la question.

Answer 1

Cela vient probablement d’un appel Response.Redirect.Consultez ce lien pour une explication :

http://dotnet.org.za/armand/archive/2004/11/16/7088.aspx

(Dans la plupart des cas, appeler Response.Redirect(url, false) résout le problème)

Answer 2

La raison la plus courante d'une ThreadAbortException est l'appel Response.End, Response.Redirect ou Server.Transfer.Microsoft a publié certaines fonctions suggérées qui devraient être utilisées à la place de ces fonctions.

Answer 3

Comme d'autres l'ont dit, cela se produit lorsque vous appelez Response.End() (ce qui se produit lorsque vous appelez Response.Redirect sans passer false comme deuxième paramètre).Cela fonctionne comme prévu ;généralement, si vous appelez Response.Redirect, vous souhaitez que la redirection se produise immédiatement.Voir ceci pour plus d'informations :

Response.Redirect et ThreadAbortException

Answer 4

Sachant qu'il existe (au moins) trois API qui utilisent en interne Thread.Abort, j'aimerais répondre en termes plus pratiques, comment déterminer quoi faire à ce sujet.

Pour nous, cette erreur a commencé à être enregistrée tout d’un coup.Qu'est ce qui a changé?Nous avons corrigé un bug dans certaines procédures de base de données traitant des plans de site.

Les journaux log4net ont montré que l'en-tête X-Forwarded-For (nous sommes derrière un NLB) était l'adresse IP de Googlebot, 66.249.78.x, ce qui a renforcé ma théorie sur le changement du plan du site conduisant Google à explorer notre site de manière plus agressive à la recherche d'images.

La première chose était de découvrir pourquoi seul le Googlebot était capable de provoquer ce problème.Aucun autre client ne déclenchait le chemin de code utilisé Response.Redirect, ou peu importe.

Donc dans le HttpApplication.Error gestionnaire, j'ai ajouté du code pour enregistrer une sortie plus détaillée avec tous les en-têtes et la plupart des données du HttpResponse et HttpContext craché pour se connecter.

Cela m'a permis de voir que le problème était que Googlebot utilisait une chaîne d'agent utilisateur iPhone et, armé de cela, j'ai pu rechercher "iPhone" dans la base de code et trouver :

private void CheckIPhoneAccess() { ... }

Et cela utilise une redirection.

Que faire à ce sujet ?

Eh bien, pour cette vieille base de code, cela ne vaut pas la peine de rétro-patcher tous les Response.Redirect appels, je vais donc baisser le niveau de journalisation pour ThreadAbortException pour la candidature.

Je vais modifier le comportement du robot d'exploration mobile de Googlebot, ce qui pas conduire à des « mensonges » sur ce que notre site sert aux mobiles puisqu'il ne redirige qu'au premier appel, il lit ensuite un cookie et affiche l'image.Googlebot ne semble pas mettre en cache ce cookie.

Ce n'est pas parfait, mais le site doit être reconstruit.probablement par une autre équipe utilisant Scala ou quelque chose comme ça, donc en termes pratiques, je pense que c'est un bon choix.J'ajouterai des commentaires et je pourrai revenir sur le problème plus tard, créer un Response.SafeRedirect extension qui résume ce conseil :

Pourquoi Response.Redirect provoque System.Threading.ThreadAbortException ?

Luc

Answer 5

La raison pour laquelle Response.Redirect donnera cette exception est que asp.net implémente cette API en interne avec Thread.Abort().Lorsque cette méthode est appelée, une ThreadAbortException spéciale est levée. Cette exception ne sera avalée par aucun bloc catch.Il sera relancé à la fin de chaque bloc catch.