Respuesta

En Visual Basic, se utiliza el bloque Try...Catch...Finally para manejar excepciones. Para relanzar una excepción después de capturarla, es decir, pasarla hacia arriba en la pila de llamadas, se utiliza el operador Throw o Throw ex.

Diferencias:

• Throw (sin parámetro) vuelve a lanzar la excepción actual, manteniendo la pila de llamadas original (Call Stack).
• Throw ex lanza el objeto de excepción, pero reinicia la pila de llamadas, perdiendo la información sobre el lugar real donde ocurrió el problema.

Se recomienda usar Throw sin parámetros para un relanzamiento correcto de la excepción, si no ha sido modificada.

Ejemplo de un relanzamiento correcto:

Try
    DangerousOperation()
Catch ex As Exception
    ' Registro...
    Throw ' se mantiene la pila de llamadas
End Try

Forma incorrecta:

Try
    DangerousOperation()
Catch ex As Exception
    Throw ex ' Pila de llamadas reiniciada, dificultando el diagnóstico
End Try

Pregunta capciosa

¿Qué sucederá con la pila de llamadas si utiliza Throw ex en lugar de Throw?

Al usar Throw sin parámetro, se conserva la pila de llamadas original, donde ocurrió la excepción. Si se usa Throw ex, la pila comienza desde la línea actual, y se pierde el lugar de origen de la excepción. Esto complica la depuración, ya que no verás en qué parte del código ocurrió el problema.

Ejemplos de errores reales por desconocer los matices del tema

---

Historia

En un gran proyecto bancario, los desarrolladores utilizaron Throw ex para lanzar errores de lógica. Al analizar los registros, fue imposible determinar el lugar de origen de las excepciones, debido a la falta de un rastreo correcto.

---

Historia

Dentro de la capa de acceso a datos, se utilizó Throw para relanzar SqlException, pero en algunos casos, la herramienta de autoformato de código lo reemplazó automáticamente por Throw ex. Esto rompió el sistema de extracción automática de datos de los registros y aumentó el tiempo de respuesta ante incidentes.

---

Historia

El intento de modificar el objeto Exception y relanzarlo usando Throw sin parámetros resultó en que los cambios no se reflejaron en los registros; solo se ayudó con la creación explícita de un nuevo objeto de excepción, manteniendo el original como InnerException.