|
Responder ![]() |
Autor | |
buho ![]() Ver perfil usuario
Enviar mensaje privado
Ver los mensajes del usuario
Visite la página de los usuarios
Añadir a la lista de amigos
Administrador ![]() ![]() Feo Unido: 10/Abril/2004 Localización: Estremera Estado: Sin conexión Puntos: 11253 |
![]() Enviado: 10/Febrero/2005 a las 14:06 |
Hola a todas y a todos
Esta entrega analiza el método que tiene VBA para la gestión de los errores generados "en tiempo de ejecución" Para ello utiliza la famosa y repudiada instrucción Goto En la práctica, el único propósito para el que se debe utilizar Goto es precisamente en la gestión de errores, y porque VBA así lo obliga. Lo podéis bajar desde este mismo servidor del Foro AQUI Saludos desde la calle Estafeta de Pamplona: Eduardo Olaz Microsoft [MVP] Access eduardoALGARROBAolaz.net ALGARROBA = @ |
|
![]() |
|
buho ![]() Ver perfil usuario
Enviar mensaje privado
Ver los mensajes del usuario
Visite la página de los usuarios
Añadir a la lista de amigos
Administrador ![]() ![]() Feo Unido: 10/Abril/2004 Localización: Estremera Estado: Sin conexión Puntos: 11253 |
![]() |
Explicación Anexa de Eduardo Olaz sobre este tema
====================================== El valor de Err.Number = 0 VBA lo interpreta como que no hay Error. Resume, aparte de hacer un salto de estos: · al mismo sitio donde se produjo el error si no se pone nada después de resume · a la instrucción siguiente con Resume Next · a la línea marcada con una etiqueta ó número con Resume Etiqueta ó Resume Número pone a 0 la propiedad Number de Err, y a "" sus propiedades de texto, mediante una llamada "implícita" al método que elimina el error, que es Clear. Err.Clear elimina totalmente el error generado. Por ello, si en un procedimiento simplemente después de un On Error Goto Etiqueta el controlador de error sólo va a hacer Resume Next, sin informar al usuario de las características del error que se ha producido, es mejor Sustituir On Error Goto ... Por On Error Resume Next, que realiza la misma función, pero sin dar aviso. No obstante, en este caso, para eliminar totalmente el error, hay que llamar explícitamente al método Clear del objeto Err Esto se puede comprobar con los dos ejemplos: PruebaResume y PruebaResume2 Con On Error GoTo ______________________________ Public Sub PruebaResume() On Error GoTo HayError ' Genero un error Err.Raise 123, _ "Prueba Resume", _ "Error generado por mí" ' Tras el primer error se produce _ Resume Next, con lo que sigue aquí _ sin errores (Err.Number = 0) MsgBox " Valor de Err.Number --> " & Err.Number _ & vbCrLf _ & Err.Description, _ vbOKOnly + vbInformation, _ " Esto no es error" ' Si se pone un Resume fuera de un control _ de Errores, genera un nuevo error Resume Salida Salida: Exit Sub HayError: Select Case Err.Number Case 123 MsgBox "Error Nº " & Err.Number _ & vbCrLf _ & Err.Description, _ vbOKOnly + vbCritical, _ " Mi error" Resume Next Case Else MsgBox "Error Nº " & Err.Number _ & vbCrLf _ & Err.Description, _ vbOKOnly + vbCritical, _ " Esto sí es un error" Resume Salida End Select End Sub ______________________________ Con On Error Resume Next ______________________________ Public Sub PruebaResume2() On Error Resume Next ' Genero un error Err.Raise 123, _ "Prueba Resume", _ "Error generado por mí" ' Tras el primer error este Resume Next _ No borra realmente Err _ La prueba: MsgBox " Valor de Err.Number --> " & Err.Number _ & vbCrLf _ & Err.Description, _ vbOKOnly + vbInformation, _ " El error sigue existiendo" ' Con On Error Resume Next _ Hay que borrar explícitamente con Err.Clear Err.Clear MsgBox " Valor de Err.Number --> " & Err.Number _ & vbCrLf _ & Err.Description, _ vbOKOnly + vbInformation, _ " Ahora no hay error" End Sub ______________________________ Access intercepta como error aquellos bucles indefinidos, ó con suficiente repeticiones, sólo si llegan a agotar el Espacio de Pila. De otra forma, VBA no tiene forma de saber si ese bucle está así escrito por el programador, o no. Cuando en una aplicación se produce un bucle indefinido, normalmente es por un fallo de la programación; lo que equivale a decir que no es un fallo de Access, o de VBA, , sino del programador. Para detectar estos errores y otros muchos, existen las pruebas, obligatorias antes de entregar un producto al cliente. Cuando se diseña un programa, de forma paralela hay que diseñar los métodos que lo van a poner a prueba. Saludos desde la calle Estafeta de Pamplona: Eduardo Olaz Microsoft [MVP] Access eduardoALGARROBAolaz.net ALGARROBA = @ |
|
![]() |
Responder ![]() |
|
Tweet
|
Ir al foro | Permisos de foro ![]() Usted No puede publicar nuevos temas en este foro Usted No puede responder a temas en este foro Usted No puede borrar sus mensajes en este foro Usted No puede editar sus mensajes en este foro Usted No puede crear encuestas en este foro Usted No puede votar en encuestas en este foro |