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 = @

Editado por buho