Whether in asp or asp.net, response.end terminates the output content and is mostly used for debugging programs. It is also very useful, similar to setting breakpoints, especially when your program has major problems, such as an infinite loop. Response.write cannot see the intermediate results. In this case, add response.end after response.write. This is very useful for viewing the intermediate results.
First let’s talk about its benefits.
It is also very useful when debugging a program. It is similar to setting breakpoints, especially if your program has major problems. For example, when there is an infinite loop, the intermediate results cannot be seen by using response.write. In this case, after response.write Add response.end, which is useful for viewing intermediate results.
However, if you use the Response.End, Response.Redirect, or Server.Transfer method, a ThreadAbortException will occur. You can catch this exception using a try-catch statement.
The Response.End method terminates the execution of the page and switches execution to the Application_EndRequest event in the application's event pipeline. The lines of code following Response.End are not executed.
This problem occurs in the Response.Redirect and Server.Transfer methods because both methods internally call Response.End.
Solution:
To resolve this issue, use one of the following methods:
• For Response.End, call the HttpContext.Current.ApplicationInstance.CompleteRequest method instead of Response.End to skip code execution for the Application_EndRequest event.
• For Response.Redirect, use the overload Response.Redirect(String url, bool endResponse), which passes false for the endResponse parameter to cancel the internal call to Response.End. For example:
Response.Redirect (Default.aspx, false);
Response.End() usage
In ASP development, you may sometimes use large sections of if...else judgments. However, if it is a dynamic Response.write content and you want to make it easier to read the code, you can use Response.End() to terminate the execution of ASP. It is similar to the usage of Break, for example:
if (userid=)or(password=) then Response.Write() Response.End() 'Here is the interrupt end if The following is the operation of reading the database if it is not empty, omitting n lines of code
In this way, when the incoming user name or password is empty, the prompt information is automatically written, and then Response.End() interrupts the program to reach the if. . . The role of else.
In addition, when using Response.End, it is when we debug the program daily, such as
To output the spliced SQL statement without executing the following code, you can do this
sql=select * from userinfo response.Write(sql)response.End()rs.open sql ,conn,1,1 'This sentence will not be executed
If you are afraid that there are too many places to add Response.End() and it will not be easy to comment out when it is officially released, you can encapsulate it with a function, such as the following code:
sub debug() Response.End()end sub
The above code is modified as follows:
sql=select * from userinfo response.Write(sql)debug()rs.open sql ,conn,1,1 'This sentence will not be executed
In this way, when it is officially released, commenting out the statements in the function debug can play a debugging role. However, there is also a problem with this. If you use too many debug(), the program may not be able to follow the instructions during debugging. Interruptions are needed. Sometimes you don't want execution to be interrupted in these places, so let's further reconstruct the debug() function, as follows:
sub debug(isBreak) 'isBreak is a parameter with a boolean value. If it is set to true, it will interrupt. Otherwise, no interrupt processing will be performed. if isBreak then Response.End() endend sub
The code when used is as follows:
sql=select * from userinfo response.Write(sql)debug(false)rs.open sql ,conn,1,1 'This sentence will be executed rs.close()sql=select * from product response.write(sql) debug(true)rs.open sql,conn,1,1 'This sentence will not be executed
Okay, this can basically meet our need to control interrupts, but it is only a simple analysis. In fact, it is still very imperfect. There may be many more debugging requirements that need to be met and further reconstruction is required. In fact, program development is a process of refactoring, refactoring, and refactoring. Otherwise, there would be so many design patterns. They are all the experiences summed up by predecessors from the actual development and refactoring process, and they are worth learning from.