Ob in asp oder asp.net, Response.end beendet den Ausgabeinhalt und wird hauptsächlich zum Debuggen von Programmen verwendet. Es ist auch sehr nützlich, ähnlich wie beim Setzen von Haltepunkten, insbesondere wenn Ihr Programm große Probleme hat, wie z. B. eine Endlosschleife. write kann die Zwischenergebnisse nicht sehen. Fügen Sie in diesem Fall „response.end“ nach „response.write“ hinzu. Dies ist sehr nützlich, um die Zwischenergebnisse anzuzeigen.
Lassen Sie uns zunächst über seine Vorteile sprechen.
Dies ist auch beim Debuggen eines Programms sehr nützlich, insbesondere wenn Ihr Programm schwerwiegende Probleme aufweist. In diesem Fall können die Zwischenergebnisse nicht angezeigt werden , nach Response.write Fügen Sie Response.end hinzu, was zum Anzeigen von Zwischenergebnissen nützlich ist.
Wenn Sie jedoch die Methoden Response.End, Response.Redirect oder Server.Transfer verwenden, tritt eine ThreadAbortException auf. Sie können diese Ausnahme mit einer Try-Catch-Anweisung abfangen.
Die Response.End-Methode beendet die Ausführung der Seite und schaltet die Ausführung auf das Application_EndRequest-Ereignis in der Ereignispipeline der Anwendung um. Die Codezeilen nach Response.End werden nicht ausgeführt.
Dieses Problem tritt bei den Methoden Response.Redirect und Server.Transfer auf, da beide Methoden intern Response.End aufrufen.
Lösung:
Um dieses Problem zu beheben, verwenden Sie eine der folgenden Methoden:
• Rufen Sie für Response.End die Methode HttpContext.Current.ApplicationInstance.CompleteRequest anstelle von Response.End auf, um die Codeausführung für das Application_EndRequest-Ereignis zu überspringen.
• Verwenden Sie für Response.Redirect die Überladung Response.Redirect(String url, bool endResponse), die false für den endResponse-Parameter übergibt, um den internen Aufruf von Response.End abzubrechen. Zum Beispiel:
Response.Redirect (Default.aspx, false);
Verwendung von Response.End()
In der ASP-Entwicklung können Sie manchmal große Abschnitte von if...else-Urteilen verwenden. Wenn es sich jedoch um einen dynamischen Response.write-Inhalt handelt und Sie das Lesen des Codes erleichtern möchten, können Sie Response.End() verwenden Beenden Sie die Ausführung von ASP. Dies ähnelt der Verwendung von Break, zum Beispiel:
if (userid=)or(password=) then Response.Write() Response.End() 'Hier ist das Interrupt-Ende if Das Folgende ist die Operation zum Lesen der Datenbank, wenn sie nicht leer ist, wobei n Codezeilen weggelassen werden
Auf diese Weise werden die Eingabeaufforderungsinformationen automatisch geschrieben, wenn der eingehende Benutzername oder das Kennwort leer ist, und dann unterbricht Response.End () das Programm, um das If zu erreichen. . . Die Rolle des Anderen.
Darüber hinaus ist es bei Verwendung von Response.End der Fall, wenn wir das Programm täglich debuggen, z
Um die gespleißte SQL-Anweisung auszugeben, ohne den folgenden Code auszuführen, können Sie dies tun
sql=select * from userinfo Response.Write(sql)response.End()rs.open sql ,conn,1,1 'Dieser Satz wird nicht ausgeführt
Wenn Sie befürchten, dass Response.End() an zu vielen Stellen hinzugefügt werden muss und das Auskommentieren nach der offiziellen Veröffentlichung nicht einfach ist, können Sie es mit einer Funktion wie dem folgenden Code kapseln:
sub debug() Response.End()end sub
Der obige Code wird wie folgt geändert:
sql=select * from userinfo Response.Write(sql)debug()rs.open sql ,conn,1,1 'Dieser Satz wird nicht ausgeführt
Auf diese Weise kann das Auskommentieren der Anweisungen in der Funktion debug eine Debugging-Rolle spielen. Wenn Sie jedoch zu viele debug() verwenden, ist dies möglicherweise nicht möglich Befolgen Sie die Anweisungen während des Debuggens. Manchmal möchten Sie nicht, dass die Ausführung an diesen Stellen unterbrochen wird. Daher rekonstruieren wir die Funktion debug() wie folgt:
sub debug(isBreak) 'isBreak ist ein Parameter mit einem booleschen Wert, wenn er auf true gesetzt ist, wird keine Interrupt-Verarbeitung durchgeführt, wenn isBreak then Response.End() ist
Der verwendete Code lautet wie folgt:
sql=select * from userinfo Response.Write(sql)debug(false)rs.open sql ,conn,1,1 'Dieser Satz wird ausgeführt rs.close()sql=select * from product Response.write(sql) debug (true)rs.open sql,conn,1,1 'Dieser Satz wird nicht ausgeführt
Okay, dies kann im Grunde unseren Bedarf an der Steuerung von Interrupts decken, aber es ist nur eine einfache Analyse. Tatsächlich müssen noch viele weitere Debugging-Anforderungen erfüllt werden, und es ist eine weitere Rekonstruktion erforderlich. Tatsächlich ist die Programmentwicklung ein Prozess des Refactorings, Refactorings und Refactorings. Ansonsten gäbe es so viele Entwurfsmuster, die von Vorgängern aus dem eigentlichen Entwicklungs- und Refactoringprozess zusammengefasst wurden, und es lohnt sich, daraus zu lernen.