Warum löst meine asp.net-Anwendung eine ThreadAbortException aus?

Question

selbsterklärende Frage.

Warum sprudelt dieses Ding in meine Try-Catchs, auch wenn nichts falsch ist?

Warum taucht es hunderte Male in meinem Protokoll auf?

Ich weiß, dass es sich um eine Neulingsfrage handelt, aber wenn diese Website ein Suchranking erreichen und Neulinge anlocken soll, müssen wir sie stellen

Answer 1

Dies kommt wahrscheinlich von einem Response.Redirect-Aufruf.Eine Erklärung finden Sie unter diesem Link:

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

(In den meisten Fällen behebt der Aufruf von Response.Redirect(url, false) das Problem.)

Answer 2

Der häufigste Grund für eine ThreadAbortException ist ein Aufruf Response.End, Response.Redirect oder Server.Transfer.Microsoft hat einige empfohlene Funktionen veröffentlicht, die anstelle dieser Funktionen verwendet werden sollten.

Answer 3

Wie andere bereits gesagt haben, tritt es auf, wenn Sie Response.End() aufrufen (was geschieht, wenn Sie Response.Redirect aufrufen, ohne false als zweiten Parameter zu übergeben).Dies funktioniert wie vorgesehen;Wenn Sie Response.Redirect aufrufen, möchten Sie normalerweise, dass die Umleitung sofort erfolgt.Weitere Informationen finden Sie hier:

Response.Redirect und die ThreadAbortException

Answer 4

Zu wissen, dass es (mindestens) drei APIs gibt, die intern verwendet werden Thread.Abort, Ich würde gerne etwas praktischer antworten, wie man herausfinden kann, was man dagegen tun kann.

Bei uns wurde dieser Fehler ganz plötzlich protokolliert.Was hat sich geändert?Wir haben einen Fehler in einer Datenbankprozedur behoben, die sich mit Sitemaps befasste.

Die log4net-Protokolle zeigten, dass der X-Forwarded-For-Header (wir stecken hinter einem NLB) die IP-Adresse des Googlebots, 66.249.78.x, war, was meine Theorie über die Sitemap-Änderung, die dazu führte, dass Google unsere Website aggressiver nach Bildern durchsuchte, bestärkte.

Zunächst galt es herauszufinden, warum nur der Googlebot dieses Problem verursachen konnte.Kein anderer Client hat den verwendeten Codepfad ausgelöst Response.Redirect, oder Wasauchimmer.

Also im HttpApplication.Error Handler habe ich etwas Code hinzugefügt, um eine besonders detaillierte Ausgabe mit allen Headern und den meisten Daten im zu protokollieren HttpResponse Und HttpContext gespuckt, um sich anzumelden.

Dadurch konnte ich erkennen, dass das Problem darin bestand, dass der Googlebot eine iPhone-User-Agent-Zeichenfolge verwendet. Damit konnte ich die Codebasis nach „iPhone“ durchsuchen und kam auf Folgendes:

private void CheckIPhoneAccess() { ... }

Und das nutzt eine Weiterleitung.

Was tun dagegen?

Nun, für diese veraltete Codebasis lohnt es sich nicht, das Ganze nachträglich zu patchen Response.Redirect Anrufe, also werde ich die Protokollierungsstufe für senken ThreadAbortException für die Bewerbung.

Ich werde das Verhalten des mobilen Crawlers des Googlebot ändern nicht führen zu „Lügen“ darüber, was unsere Website für Mobiltelefone bietet, da sie nur beim ersten Zugriff umleitet, anschließend ein Cookie liest und das Bild anzeigt.Googlebot scheint dieses Cookie nicht zwischenzuspeichern.

Es ist nicht perfekt, aber die Seite muss neu aufgebaut werden.wahrscheinlich von einem anderen Team, das Scala oder so etwas verwendet, also halte ich das praktisch für eine gute Wahl.Ich werde Kommentare hinzufügen und das Problem später möglicherweise noch einmal aufgreifen und eine erstellen Response.SafeRedirect Erweiterung, die diesen Rat zusammenfasst:

Warum verursacht Response.Redirect eine System.Threading.ThreadAbortException?

Lukas

Answer 5

Der Grund, warum Response.Redirect diese Ausnahme ausgibt, ist, dass asp.net diese API intern mit Thread.Abort() implementiert.Wenn diese Methode aufgerufen wird, wird eine spezielle ThreadAbortException ausgelöst. Diese Ausnahme wird von keinem Catch-Block verschluckt.Es wird am Ende jedes Catch-Blocks erneut geworfen.