Manejo de errores con TRY y CATCH

Clase 17 de 26Curso de Gestión de Bases de Datos con SQL Server

Resumen

Ejecutar una transacción sin manejo de errores es dejar una trampa activa en tu base de datos. Si algo falla y no existe un bloque de captura, la transacción queda abierta, bloqueando recursos de forma indefinida. Comprender cómo integrar try catch dentro de transacciones es lo que separa un procedimiento almacenado de prueba de uno listo para producción.

¿Por qué un fallo silencioso es más peligroso que uno ruidoso?

Un procedimiento almacenado que falla en silencio genera consecuencias graves. Si un cierre de mes se interrumpe a mitad del proceso y nadie lo detecta, el gerente de finanzas toma decisiones con datos incompletos. Eso representa un riesgo real para cualquier organización.

El bloque try catch convierte un fallo silencioso en un error registrado, controlado y reversible [01:00]. La lógica es directa:

  • El try (begin try) envuelve toda la operación que se quiere intentar.
  • Si algo falla dentro del try, se ejecuta automáticamente el catch (begin catch).
  • Dentro del catch se realiza el rollback de la transacción, revirtiendo todos los cambios parciales.
  • Se registra el error con datos precisos para diagnóstico.

Antes, la transacción se iniciaba directamente. Ahora se coloca dentro del bloque try, de modo que cualquier fallo activa el catch de inmediato [01:22].

¿Qué funciones de error se capturan dentro del catch?

Cuando el try falla, el catch tiene acceso a un conjunto de funciones de error que permiten identificar con exactitud qué ocurrió [03:06]. Estas funciones son:

  • ERROR_NUMBER(): devuelve el número identificador del error.
  • ERROR_MESSAGE(): muestra el mensaje descriptivo del error.
  • ERROR_SEVERITY(): indica la severidad, por ejemplo dieciséis.
  • ERROR_STATE(): entrega el estado del error.
  • ERROR_LINE(): señala la línea exacta donde ocurrió la falla.
  • ERROR_PROCEDURE(): indica el procedimiento donde se produjo el error, si aplica.

En una demostración práctica, al provocar un error con RAISERROR(50000, 16, 1, 'error de demostración'), el catch devuelve todos estos valores de forma ordenada [03:40]. Si no se estaba invocando ningún procedimiento, el campo de procedimiento queda vacío.

¿Cómo se estructura el SP de cierre de mes con try catch?

El procedimiento almacenado de cierre de mes, que ya existía sin manejo de errores, se reestructura con la siguiente lógica [04:25]:

  • Se inicia con begin try.
  • Primero se ejecutan las validaciones de parámetros: que la fecha sea válida y que el código de país sea correcto. Si fallan, se lanzan errores específicos como el 50001 o 50002.
  • Después de las validaciones, se inicia la transacción con begin transaction.
  • Se ejecutan los INSERT INTO correspondientes al resumen mensual y al log de cierre.
  • Si todo sale bien, se ejecuta el commit transaction y termina el try.

Si algo falla, el flujo pasa al catch [05:30]:

  • Verifica si la transacción está abierta mediante XACT_STATE().
  • Ejecuta el rollback transaction para revertir cualquier cambio parcial.
  • Registra el error en el log de cierre con todos los valores capturados por las funciones de error.
  • Finaliza el catch.

¿Cómo verificar que el try catch funciona correctamente?

Para probar el mecanismo, se provoca un error de forma consciente [06:45]. Por ejemplo, declarando un mes trece o un año 1990 con mes catorce, valores que no existen. Al ejecutar el procedimiento:

  • El resultado devuelve "error".
  • El SP no se ejecuta.
  • Al consultar el log de cierre, aparece registrado: "parámetros de fecha inválidos" [07:30].

Esta combinación de try catch, begin transaction y rollback es lo que hace que un procedimiento almacenado sea seguro para producción. Sin ella, cualquier proceso de múltiples pasos representa un riesgo de inconsistencia de datos.

Como desafío, agrega el try catch completo al SP de cierre de mes y prueba tres escenarios: un cierre exitoso en la primera ejecución, un cierre duplicado del mismo mes que debe capturar el error 50002 y un error interno simulado con un insert inválido dentro de la transacción. Verifica que tanto el resumen mensual como el log de cierre queden en el estado correcto en cada caso. Comparte tus resultados en los comentarios.