Estoy intentando depurar algún código usando Response.Write, pero cuando ejecuto el código, se saltea esa declaración y los errores salen en algún punto del código.Depuración con Response.Write en el clásico ASP
¿Cómo puedo obtener mis declaraciones Response.Write para mostrar sin los otros errores que vienen?
Uso con bastante frecuencia Response.End cuando tengo que ver un estado en un lugar determinado en una página.
Pruebe Response.Flush después de sus declaraciones de depuración, o establezca Response.Buffer en falso.
Deberá usar la instrucción "on error resume next" en la parte superior de su página ASP. Esto resolverá su problema cuando ocurra un error, se moverá a la próxima línea en lugar de arrojar un error.
Puede consultar este enlace http://www.powerasp.com/content/new/on-error-resume-next.asp como referencia.
feliz Codificación
comentar la línea que da el error y ver lo que el respnse.write está mostrando es la única cosa razonable.
No utilice el on error resume next mientras desarrolla sus páginas. Debes asegurarte de que estás construyendo tus páginas correctamente y de que estás produciendo el código correcto. No verá ningún error si usa on error resume next.
on error resume next solo debe utilizarse, en mi opinión, en las acciones de la base de datos y en el código entregado (sin desarrollo). En ese caso, debe usar la construcción
if Err.Number <> 0 then
para probar cualquier error. Simplemente no puede hacer eso después de cada línea en asp si ha puesto la declaración on error resume next en la parte superior de su código, pero ciertamente hace sentido en el código de manejo de la base de datos.
Utilizamos Visual Studio 2008 para depurar páginas asp clásicas. Puede adjuntar al proceso de IIS y "recorrer" la página. Es muy dulce. Estos son los pasos:
Obtenga la última ASP clásica del control de fuente.
Instale IIS (si no lo ha hecho). FYI ... Estoy usando IIS 5.1.
Cree un directorio virtual llamado "classicDebug" apuntando a su directorio local (C: \ Websites \ ClassicWebSite).
Ver las propiedades del directorio virtual, pestaña Directorio virtual.
Habilite la casilla de verificación "Acceso de fuente de script".
Botón de configuración, pestaña Opciones: compruebe todo.
Pestaña de depuración: compruebe todo.
7a. En la pestaña ASP.NET, selecciona 2.x
carga hasta (no ejecutar o depurar o F5) la página web en VS.NET 2008.
Editar su global.asa en consecuencia (fuentes de datos, y caminos).
Encuentra la página .asp que deseas "recorrer" y establece un punto de interrupción en la parte superior (o en algún lugar).
Abra IE, y vaya a su página.
Volver a VS.NET y seleccione Depurar -> Asociar al proceso
Verificar "procesos de demostración de todos los usuarios" y seleccionar el proceso. Para mí (IIS 5.1), el nombre del proceso es dllhost.exe que se ejecuta con la cuenta IWAM_COMPUTERNAME con el tipo "Script, T-SQL, Managed, x86".
Visite su página usando IE ... VS.NET debería romperse.
gracias por el paso a paso al hacerlo con vs 2008.Actualmente uso un desarrollador web visual y no permite unir procesos – chobo
Esto podría ayudar como una alternativa a response.write.
Armado este ASP incluye clase que funciona con Firebug + FirePHP. Le permite registrar valores (incluidas cadenas, matrices multidimensionales e incluso objetos creados con json.asp) en la consola Firebug y ver los objetos de colección incorporados de ASP que pueden ayudar (particularmente con Ajax donde no se pueden generar datos de depuración sin rompiendo la respuesta json.) Los tiempos y errores de carga del script Ajax se registran automáticamente para una visualización rápida.
https://github.com/dmeagor/ClassicASP-FirePHP
basta con incluir el archivo y registro de utilización (somevalue) para enviar variables con formato a la consola de Firebug.
publicado bajo licencia de código abierto MIT
Hablando de opciones alternativas, de David Meagor puesto, también se puede escribir rastros en un archivo. Aquí hay un ejemplo de cómo escribir en archivos: http://www.4guysfromrolla.com/webtech/040699-1.shtml
Si lo desea, puede incluso colocar las subrutinas de rastreo en un archivo de inclusión y usarlo en todas sus páginas cuando lo necesite.
Otra solución que estamos usando es poner los métodos de rastreo en un ensamblado .Net, registrarlo como COM y llamarlo usando CreateObject.
Estas opciones le permitirán mantener sus rastros en un archivo que puede revisar más tarde y compartir con otros desarrolladores.
Yo personalmente uso una combinación de estos enfoques: reviso los archivos de registro, uso puntos de interrupción e incluso lugar de vez en cuando un Response.Write.
Otra cosa: active y revise los registros de IIS: a menudo le indicarán en qué línea se rompió su página. Puede leer aquí cómo habilitar o deshabilitar registros para la ASP clásica: https://technet.microsoft.com/en-us/library/hh831387.aspx.
no se olvide de cerrar ese bloque de error con un "on error goto 0" al final –
No creo que "on error goto 0" funcione en asp clásico (al menos eso es lo que estaba experimentando una vez. – Edelcom
@Edelcom: "On error goto next" y "On error goto 0" son las dos únicas operaciones "en error" que funcionan en VBScript – AnthonyWJones