Ya sea en asp o asp.net, Response.end finaliza el contenido de salida y se usa principalmente para depurar programas. También es muy útil, similar a establecer puntos de interrupción, especialmente cuando su programa tiene problemas importantes, como una respuesta infinita. write no puede ver los resultados intermedios. En este caso, agregue respuesta.end después de respuesta.escribir. Esto es muy útil para ver los resultados intermedios.
Primero hablemos de sus beneficios.
También es muy útil al depurar un programa. Es similar a establecer puntos de interrupción, especialmente si su programa tiene problemas importantes. Por ejemplo, cuando hay un bucle infinito, los resultados intermedios no se pueden ver usando respuesta. , después de respuesta.escribir Agregue respuesta.end, que es útil para ver resultados intermedios.
Sin embargo, si utiliza el método Response.End, Response.Redirect o Server.Transfer, se producirá una ThreadAbortException. Puede detectar esta excepción utilizando una declaración try-catch.
El método Response.End finaliza la ejecución de la página y cambia la ejecución al evento Application_EndRequest en la canalización de eventos de la aplicación. Las líneas de código que siguen a Response.End no se ejecutan.
Este problema ocurre en los métodos Response.Redirect y Server.Transfer porque ambos métodos llaman internamente a Response.End.
Solución:
Para resolver este problema, utilice uno de los siguientes métodos:
• Para Response.End, llame al método HttpContext.Current.ApplicationInstance.CompleteRequest en lugar de Response.End para omitir la ejecución de código para el evento Application_EndRequest.
• Para Response.Redirect, utilice la sobrecarga Response.Redirect(String url, bool endResponse), que pasa false para el parámetro endResponse para cancelar la llamada interna a Response.End. Por ejemplo:
Respuesta.Redirect (Default.aspx, falso);
Uso de Response.End()
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() Response.End() 'Aquí está el final de la interrupción if 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=select * de la respuesta de información del usuario.Write(sql)response.End()rs.open sql,conn,1,1 'Esta oración 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:
sub debug() Respuesta.End()fin sub
El código anterior se modifica de la siguiente manera:
sql=select * de la respuesta de información del usuario.Write(sql)debug()rs.open sql,conn,1,1 'Esta oración 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=select * de la respuesta de información del usuario.Write(sql)debug(false)rs.open sql,conn,1,1 'Esta oración se ejecutará rs.close()sql=select * de la respuesta del producto.write(sql) debug (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.