De ce cererea mea asp.net aruncă ThreadAbortException?

Cel mai frecvent motiv pentru care un ThreadAbortException este de asteptare Response.End, Response.Redirect sau Server.Transfer . Microsoft a publicat câteva funcții sugerate care ar trebui utilizate în locul acestor funcții.

Probabil că vine de la un apel Response.Redirect. Verificați acest link pentru o explicație:

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

(În cele mai multe cazuri, apelând la Response.Redirect (url, false) rezolvă problema)

Motivul pentru care Response.Redirect va da această excepție este asp.net implementarea internă a acestui API cu Thread.Abort (). Atunci când se numește această metodă, se aruncă un ThreadAbortException special. Această excepție nu va fi înghițită de nici un bloc de captură. Acesta va fi aruncat la sfârșitul fiecărui bloc de captură.

Știind că există (cel puțin) trei API-uri care utilizează intern Thread.Abort , aș dori să răspund în termeni mai practici, cum să aflu ce să fac.

Pentru noi, această eroare a început să fie înregistrată tot timpul. Ce sa schimbat? Am rezolvat o eroare într-o procedură bazată pe baze de date.

Jurnalele log4net au arătat că antetul X-Forwarded-For (fost în spatele unui NLB) a fost adresa IP a Googlebot, 66.249.78.x, care a susținut teoria despre schimbarea sitemap-ului, ceea ce a dus la accesarea cu crawlere a site-ului Google pentru a căuta imagini mai agresive.

Primul lucru a fost să aflăm de ce numai Googlebot a reușit să provoace această problemă. Niciun alt client nu a declanșat calea de cod care utilizează Response.Redirect sau orice altceva.

Deci, în manipularea HttpApplication.Error , am adăugat un cod pentru a înregistra jurnalul extra detaliat cu toate anteturile și majoritatea datelor din HttpResponse și HttpContext a vrut să se jurnalizeze.

Acest lucru lasă-mă să văd că problema a fost că Googlebot folosește un șir de agenți de utilizator iPhone și înarmat cu asta, am reușit să caut codul pentru "iPhone" și să vină cu:

private void CheckIPhoneAccess() { ... }

Și asta folosește un Redirect.

Ce să faci?

Ei bine, pentru această bază de coduri în vârstă, nu merită să repetați toate apelurile Response.Redirect , așa că voi reduce nivelul de logare pentru ThreadAbortException pentru aplicație.

Voi schimba comportamentul crawlerului mobil Googlebot, care nu va duce la "minciuni" despre ceea ce site-ul nostru servește pentru telefoane mobile, deoarece redirecționează doar la prima lovitură, după care citește un cookie și afișează imaginea . Googlebot nu pare să cacheze acel cookie.

Nu este perfect, dar site-ul urmează să fie reconstruit. probabil de o altă echipă care utilizează Scala sau ceva, așa că, în termeni practici, cred că aceasta este o alegere bună. Voi adăuga comentarii și pot revizui ulterior problema, construi o extensie Response.SafeRedirect care încapsulează acest sfat:

De ce răspunsul.Redirect cauzează System.Threading.ThreadAbortException?

Luke

Așa cum au spus ceilalți, aceasta apare atunci când apelați Response.End() (care apare când apelați Response.Redirect fără a trece false ca al doilea parametru). Acest lucru funcționează așa cum a fost proiectat; de obicei, dacă apelați Response.Redirect, doriți ca redirecționarea să aibă loc imediat. Consultați aceasta pentru mai multe informații:

Response.Redirect și ThreadAbortException