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’s similar to the usage of Break
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:
Copy the code code as follows:if (userid=)or(password=) then
Response.Write(<script lanuage=javascript>alert('UserName or Password is Empty!');location.href='../default.asp';</script>)
Response.End() 'The end if is interrupted here. 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
Copy the code code as follows: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:
Copy the code code as follows:subdebug()
Response.End()
end sub
The above code is modified as follows:
Copy the code code 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:
Copy the code code 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.