Uso de Response.End() en asp

En el desarrollo de ASP, a veces es posible utilizar grandes secciones de juicios if...else. Sin embargo, si se trata de un contenido dinámico de Response.write y desea que sea más fácil de leer el código, puede utilizar Response.End() para. finalizar la ejecución de ASP. Es similar al uso de Break.

En el desarrollo de ASP, a veces es posible utilizar grandes secciones de juicios if...else. Sin embargo, si se trata de un contenido dinámico de Response.write y desea que sea más fácil de leer el código, puede utilizar Response.End() para. finalizar la ejecución de ASP. Es similar al uso de Break, por ejemplo:

si (id de usuario =) o (contraseña =) entonces

Response.Write(<script lanuage=javascript>alert('¡El nombre de usuario o la contraseña están vacíos!');location.href='../default.asp';</script>)

Response.End() 'El final si se interrumpe aquí. La siguiente es la operación de leer la base de datos si no está vacía, omitiendo n líneas de código.

De esta manera, cuando el nombre de usuario o la contraseña entrantes están vacíos, la información del mensaje se escribe automáticamente y luego Response.End() interrumpe el programa para llegar al if. . . El papel del otro.

Además, al usar Response.End, es cuando depuramos el programa diariamente, como por ejemplo

Para generar la declaración SQL empalmada sin ejecutar el siguiente código, puede hacer esto

sql=seleccionar * de información de usuario

respuesta.Escribir(sql)

respuesta.Fin()

rs.open sql, conn,1,1 'Esta frase no se ejecutará

Si teme que haya demasiados lugares para agregar Response.End() y no será fácil comentar cuando se lance oficialmente, puede encapsularlo con una función, como el siguiente código:

subdepurar()

Respuesta.Fin()

sub final

El código anterior se modifica de la siguiente manera:

sql=seleccionar * de información de usuario

respuesta.Escribir(sql)

depurar()

rs.open sql, conn,1,1 'Esta frase no se ejecutará

De esta manera, cuando se lance oficialmente, comentar las declaraciones en la función de depuración puede desempeñar un papel de depuración. Sin embargo, también existe un problema con esto: si usa demasiados debug (), es posible que el programa no pueda hacerlo. Siga las instrucciones durante la depuración. Se necesitan interrupciones. A veces no desea que la ejecución se interrumpa en estos lugares, así que reconstruyamos la función debug() de la siguiente manera:

sub debug(isBreak) 'isBreak es un parámetro con un valor booleano. Si se establece en verdadero, interrumpirá. De lo contrario, no se realizará ningún procesamiento de interrupción si isBreak entonces Response.End() endend sub.

El código cuando se utiliza es el siguiente:

sql=seleccionar * de información de usuario

respuesta.Escribir(sql)

depurar (falso)

rs.open sql,conn,1,1 'Esta frase se ejecutará rs.close()

sql=seleccionar * del producto

respuesta.escribir(sql)

depurar (verdadero)

rs.open sql,conn,1,1 'Esta frase no se ejecutará

Bien, esto básicamente puede satisfacer nuestra necesidad de controlar las interrupciones, pero es solo un análisis simple. De hecho, todavía es muy imperfecto. Es posible que deban cumplirse muchos más requisitos de depuración y se requiera una reconstrucción adicional. De hecho, el desarrollo del programa es un proceso de refactorización, refactorización y refactorización. De lo contrario, habrá tantos patrones de diseño. Son todas las experiencias resumidas por los predecesores del proceso de desarrollo y refactorización real, y vale la pena aprender de ellas.