🚀The world's best VBA AI has evolved. ExcelMaster is now an autonomous Agent.Read more →
Back to Blog

VBA End en Excel — End vs End Sub vs Exit Sub vs Stop

|

VBA End en Excel — End vs End Sub vs Exit Sub vs Stop

TL;DR — La sentencia End a secas detiene la macro entera de inmediato: borra cada variable (incluidas las de nivel de módulo y las Static), cierra los UserForms y se salta cualquier limpieza que tuvieras pendiente. Eso es algo distinto de End Sub (que solo marca dónde termina un Sub), de Exit Sub (que vuelve desde un procedimiento y deja que el programa continúe) y de Stop (que pausa en el depurador). Casi nunca quieres el End a secas. Para abandonar un procedimiento, usa Exit Sub.

Sub WhyEndIsDangerous()
    Application.ScreenUpdating = False
    ' ... work ...
    If somethingWrong Then End       ' se detiene AHORA - ScreenUpdating se queda en False!
    ' ... more work ...
    Application.ScreenUpdating = True ' esta linea de limpieza nunca se ejecuta tras End
End Sub

Cuatro construcciones de VBA contienen la palabra end, y confundirlas causa errores de verdad. Solo una de ellas —el End a secas— detiene realmente tu programa, y lo hace del modo más brusco posible. Las demás simplemente cierran un bloque o vuelven de un procedimiento. Saber cuál es cuál es la diferencia entre una macro que se limpia tras de sí y otra que deja Excel en un estado a medio configurar.

Lo que aprenderás

  • Qué hace en realidad la sentencia End a secas, y cuánto estado destruye
  • Por qué End, End Sub, End If, Exit Sub y Stop son cinco cosas distintas
  • El error de verdad: cómo End se salta tu limpieza y deja ScreenUpdating o los eventos desactivados
  • Por qué End borra las variables de nivel de módulo y Static que una vuelta normal conservaría
  • Cuándo (si es que alguna vez) End es la opción correcta, y qué usar en su lugar
  • En qué se diferencia Stop de End: pausar para depurar frente a terminar

El modelo mental: End es el enchufe, no la puerta

Alinea los cuatro parecidos según cuánto detienen:

End If      ' cierra un bloque If          - no detiene nada; un marcador estructural
End Sub     ' marca el final de un Sub     - el procedimiento acaba aqui igualmente
Exit Sub    ' vuelve de ESTE procedimiento - el programa sigue corriendo
End         ' termina la macro ENTERA      - todo se detiene, nada se limpia

End Sub y End If son puntuación: le dicen a VBA dónde termina un bloque. No se «ejecutan». Exit Sub es una puerta de salida de un procedimiento: te vas, el llamador continúa, tu limpieza se ejecuta. El End a secas es el enchufe: detiene toda la pila de llamadas de golpe, como si hubieras pulsado el botón de Reset en el editor. Todo lo que hay aguas abajo —el llamador, el llamador del llamador, la línea de limpieza que escribiste dos líneas más abajo— simplemente se abandona. Esa única distinción, puerta frente a enchufe, es toda la página.

Lo que la sentencia End a secas destruye en realidad

End hace mucho más que «detener el código». Cuando se dispara, VBA desmonta todo el estado en tiempo de ejecución de tu proyecto:

  • Todas las variables se reinician: las variables locales, de nivel de módulo y Static pierden sus valores.
  • Todos los UserForms abiertos se descargan, sin que sus eventos QueryClose o de limpieza se ejecuten con normalidad.
  • La pila de llamadas se descarta: ningún procedimiento que haya en ella llega a terminar ni a ejecutar sus líneas restantes.
  • Los manejadores On Error se limpian, y el estado en tiempo de ejecución del proyecto VBA se reinicia como si acabara de arrancar.

Lo que no hace es deshacer nada de lo ya hecho al libro o a Application. Ahí está el meollo del peligro. Si pusiste Application.ScreenUpdating = False al principio y disparas End a mitad de camino, la actualización de pantalla se queda apagada, porque la línea que la habría vuelto a encender es una de las muchas líneas que End acaba de abandonar.

El error de verdad: End se salta tu limpieza

La mayoría de las macros no triviales configuran algún estado de Excel al principio y lo restauran al final:

Sub Report()
    Application.ScreenUpdating = False
    Application.EnableEvents = False

    If Not FileExists() Then End    ' <-- la trampa

    ' ... build the report ...

    Application.EnableEvents = True     ' nunca se alcanza si End se disparo
    Application.ScreenUpdating = True   ' nunca se alcanza si End se disparo
End Sub

Si FileExists devuelve False, ese End detiene todo en el acto. EnableEvents y ScreenUpdating se quedan en False, así que el Excel del usuario ahora ignora en silencio los eventos de hoja y no se repinta: un ticket de soporte de «Excel congelado» que parece un cierre inesperado pero en realidad es solo limpieza omitida. El arreglo es volver, no terminar: sustituye End por Exit Sub, y coloca las líneas de restauración donde siempre se ejecuten (un único camino de salida, o un manejador de errores). Exit Sub abandona el procedimiento pero deja que tu limpieza —y el resto del programa— se ejecute.

End borra las variables Static y de nivel de módulo

Hay una consecuencia más sutil que merece su propia nota. Una vuelta normal (Exit Sub, o simplemente llegar a End Sub) deja intactas las variables de nivel de módulo y Static: ese es todo su sentido, persistir entre llamadas. El End a secas las tira junto con todo lo demás:

' Module level
Dim gRunCount As Long

Sub Tick()
    gRunCount = gRunCount + 1     ' pensada para acumular entre ejecuciones
    If gRunCount > 100 Then End   ' End reinicia gRunCount de vuelta a 0!
End Sub

Si alguna parte de tu diseño depende de que el estado sobreviva entre ejecuciones de la macro —un contador, un objeto en caché, una configuración cargada— un End perdido lo reinicia en silencio, y el fallo aparece mucho después como «la cuenta no para de empezar de cero». Una razón más para que el End a secas sea raro y deliberado.

Stop no es End: pausa para depurar, no termina

Stop parece emparentado pero hace lo contrario de terminar. Suspende la ejecución y te deja caer en el editor de VBA en esa línea, en modo de interrupción, con cada variable aún viva para que puedas inspeccionarlas, exactamente como un punto de interrupción que hubieras escrito en el código:

Sub Investigate()
    Dim total As Double
    total = ComputeTotal()
    Stop                     ' pausa aqui en el editor; total sigue siendo legible
    Range("A1").Value = total
End Sub

Usa Stop mientras depuras y quítalo antes de entregar (a diferencia de un punto de interrupción de F9, Stop vive en el código fuente, así que uno olvidado detendrá la macro de un usuario en el editor). End termina; Stop pausa. Ninguno es algo que quieras que se dispare en código que ejecutan tus usuarios; para observar una macro en marcha sin detenerla, mira VBA Debug.Print.

¿Cuándo es End alguna vez la opción correcta?

Rara vez, y siempre de forma deliberada. Los casos de uso honestos son estrechos: una condición catastrófica e irrecuperable en una herramienta autónoma donde prefieres detenerlo todo antes que arriesgarte a continuar con un estado erróneo, o desmontar una aplicación no modal dirigida por un UserForm donde de verdad quieres reiniciar todo el proyecto. Incluso entonces, prefiere llegar a una única salida limpia —restaurar los ajustes de Application, cerrar lo que abriste— y después detenerte. En las macros del día a día, la respuesta a «¿cómo me detengo aquí?» es Exit Sub (abandonar este procedimiento) o reestructurar para que el código llegue a End Sub por sí solo. Si estás tecleando el End a secas, detente y asegúrate de que de verdad quieres decir terminarlo todo, saltarse toda la limpieza.

Cómo te ayuda ExcelMaster

El End a secas es una palabra pequeña con un radio de explosión desmesurado, y su daño es invisible hasta que un usuario reporta un Excel «congelado» que en realidad es solo ScreenUpdating dejado apagado. Los errores son usar End cuando querías decir Exit Sub, y dejar un Stop en código entregado.

ExcelMaster escribe procedimientos que salen por una única salida limpia: Exit Sub para volver, líneas de restauración que siempre se ejecutan, y ningún End o Stop perdido en el código que tus usuarios tocan. Cuando una macro necesita retirarse pronto, lo hace sin dejar Excel a medio configurar. Tú conservas el libro y el código.

Preguntas frecuentes

¿Qué hace la sentencia End en VBA?

La sentencia End a secas termina de inmediato toda la macro. Reinicia todas las variables (incluidas las de nivel de módulo y Static), descarga los UserForms abiertos, descarta la pila de llamadas y limpia los manejadores On Error, pero no deshace los cambios ya hechos al libro o a Application, así que cualquier limpieza que tuvieras pendiente se omite. Para abandonar un procedimiento sin esto, usa Exit Sub.

¿Cuál es la diferencia entre End y End Sub?

End Sub simplemente marca dónde termina un procedimiento Sub: es un marcador estructural, y el procedimiento terminaría ahí de todos modos. El End a secas, escrito por sí solo, termina todo el programa en el acto, dondequiera que aparezca. End Sub cierra un bloque; End lo detiene todo.

¿Debería usar End para detener una macro?

Normalmente no. Para abandonar el procedimiento actual, usa Exit Sub, que vuelve al llamador y deja que tu limpieza se ejecute. El End a secas se salta toda la limpieza y puede dejar ScreenUpdating apagado o los eventos deshabilitados, produciendo un Excel que parece congelado. Reserva End para situaciones raras, deliberadas e irrecuperables.

¿Cuál es la diferencia entre End y Stop?

End termina la macro y limpia su estado. Stop pausa la ejecución y te deja caer en el editor de VBA en modo de interrupción, con todas las variables aún vivas, para que puedas depurar, como un punto de interrupción escrito en el código. Quita Stop antes de entregar, porque a diferencia de un punto de interrupción de F9 vive en el código fuente y detendrá la macro de un usuario.

¿Por qué ScreenUpdating sigue apagado después de ejecutar mi macro?

Lo más probable es que un End a secas (o un error no controlado) detuviera la macro antes de la línea que vuelve a poner Application.ScreenUpdating = True. Como End se salta el código restante, la restauración nunca se ejecutó. Sustituye End por Exit Sub y coloca tus líneas de restauración en un único camino de salida o en un manejador de errores para que siempre se ejecuten.

Probado en

Probado en: Excel 365 (Windows 11), VBA 7.1 — última verificación el 24/09/2026.

Guías relacionadas: VBA Exit For · VBA GoTo · VBA On Error · VBA Debug.Print · VBA Sub