SQL Server incorpora diferentes alternativas de Control de Errores para el desarrollo y programación en Transact-SQL, algunas más conocidas (ej: la función del sistema @@ERROR o la sentencia RAISERROR), otras más desconocidas (ej: la opción de configuración XACT_ABORT), y otras relativamente nuevas al incorporarse en la versión SQL Server 2005 (ej: bloques TRY/CATCH).
A continuación, vamos a comentar estas distintas alternativas, a nivel introductorio, con el fin de servir de una primera orientación de las posibilidades de programación control de errores en SQL Server con Transact-SQL (TSQL), esperando que para algunos lectores, pueda incluso ser una información suficiente para salir del paso ;-)
Utilizar @@ERROR para programar el Control de Errores
Esta función del sistema debe utilizarse inmediatamente después de cada sentencia, de tal modo, que devuelve un cero o bien el código de error que se pueda haber producido. Habitualmente, se suelen utilizar bloques del tipo IF @@ERROR<>0. El principal inconveniente es que requiere realizar este control de errores después de cada sentencia. Por ejemplo, si tenemos un procedimiento almacenado con siete sentencia DML (ej: INSERT, UPDATE, etc.), deberemos realizar la comprobación de @@ERROR siete veces, una vez después de cada sentencia DML, lo cual complica y hace más pesado nuestro código. Incluso en ocasiones, nos encontraremos sentencias tipo IF @@ERROR<> GOTO TrataError (dios! utilizando incluso saltos incondicionales, como con el Spectrum y el Amstrad CPC, jeje ;-). Por desgracia, es una forma de control de errores algo habitual en procedimientos almacenados de SQL Server 2000 (bueno, en procedimientos almacenados y en cualquier bloque de código Transact-SQL).
Un problema típico, es cuando se necesitan consultar varias funciones del sistema, como @@ERROR y @@ROWCOUNT. En éste caso, NO se deben consultar las dos variables en sentencias diferentes (recordar que tienen efecto en la consulta inmediatamente anterior), por lo que habrá que declarar y utilizar algunas variables temporales, y depositar en ellas el resultado de consultar estas variables del sistema, de forma similar a:
| SELECT @TMP_ERROR=@@ERROR, @TEMP_ROWCOUNT=@@ROWCOUNT |
Seguidamente, podremos consultar dichas variables temporales, que almacenarán el valor deseado. Si no lo hacemos de este modo, tendremos un problema. Imaginemos el siguiente código:
SELECT @TEMP_ROWCOUNT=@@ROWCOUNT
SELECT @TMP_ERROR=@@ERROR |
La segunda línea de código estará haciendo referencia a si la línea anterior ha generado algún error. La confusión de esto viene dada, porque en ocasiones se ponen estas dos líneas detrás de un bloque de código, y se piensa que la segunda sentencia (la de @@ERROR) tiene efecto sobre el bloque de código previo, cuando NO es así, tiene efecto sobre la línea de código inmediatamente anterior (la del @@ROWCOUNT), por lo tanto dicha gestión de errores simplemente no funcionará ¿visto? Sigamos.
Utilizar SET XACT_ABORT para programar Transacciones
Resulta muy cómodo utilizar la opción XACT_ABORT para la programación de transacciones. Al activar esta opción (SET XACT_ABORT ON), si se produce un error en tiempo de ejecución, SQL Server deshará completamente todas las transacciones abiertas. Esto simplifica enormemente la programación de transacciones, y además, está disponible desde SQL Server 2000 (toma ya ;-), y así evitamos tener que hacer la tediosa tarea de comprobar el valor de @@ERROR después de cada sentencia para poder deshacer la transacción correctamente, y que en caso de errores no se confirmen resultados parciales.
Sin activar XACT_ABORT, que es el comportamiento por defecto de SQL Server (SET XACT_ABORT OFF), sería necesario comprobar @@ERROR sucesivas veces (ojo, que estoy descartando el uso de TRY/CATCH para ahora, y que veremos después), como en el siguiente ejemplo:
BEGIN TRAN
INSERT INTO tbl VALUES (1)
IF @@ERROR<>0 GOTO TrataError
INSERT INTO tbl VALUES (1) -- Violación de Clave
IF @@ERROR<>0 GOTO TrataError
INSERT INTO tbl VALUES (3)
IF @@ERROR<>0 GOTO TrataError
COMMIT TRAN
RETURN
TrataError:
ROLLBACK TRAN
RETURN;
|
Sin embargo, utilizando XACT_ABORT activado resulta mucho más sencillo, teniendo la garantía de que se confirmará o deshará la transacción por completo sin necesidad de programar las comprobaciones de la función del sistema @@ERROR:
SET XACT_ABORT ON
BEGIN TRAN
INSERT INTO tbl VALUES (1)
INSERT INTO tbl VALUES (1) -- Violación de Clave
INSERT INTO tbl VALUES (3)
COMMIT TRAN RETURN
|
El principal caso de uso de XACT_ABORT es el ejemplo anterior, para el manejo de transacciones, eso sí, cuando NO es necesario realizar una gestión más completa de los errores, ya que si se desea programar un Control de Errores más complejo (ej: registrar el error producido, imprimir - print - mensajes personalizados para cada error, etc.), al menos hasta SQL Server 2000 es necesario sufrir del uso de la función de sistema @@ERROR (claro, que desde SQL Server 2005, podemos utilizar TRY/CATCH).
Utilizar TRY/CATCH para programar el Control de Errores
La gestión de errores a través de bloques TRY/CATCH está disponible desde SQL Server 2005, simplificándose enormemente la gestión de errores en código Transact-SQL (como en el caso de la programación de procedimientos almacenados). Cualquier error que se produzca dentro del bloque TRY provocará que se salte a la ejecución del bloque CATCH sin enviar ningún error al cliente, mientras, que cualquier error que se produzca dentro del bloque CATCH SI se enviará al cliente (excepto que anidemos estructuras TRY/CATCH). Así, la ejecución de sentencias RAISERROR dentro de bloques TRY fuerza que se salte la ejecución al correspondiente bloque CATCH.
BEGIN TRY
BEGIN TRAN
INSERT INTO tbl VALUES (1)
INSERT INTO tbl VALUES (1) -- Violación de Clave
INSERT INTO tbl VALUES (3)
COMMIT TRAN
END TRY
BEGIN CATH
ROLLBACK TRAN
RAISERROR('Cachis... que se ha producido un error.', 16, 1);
END CATCH
|
De éste modo, dentro del bloque CATCH podemos hacer uso de nuevas funciones del sistema para registrar el error producido o lanzar el error (RAISERROR) a la aplicación cliente. En particular, podemos utilizar las siguientes funciones:
- ERROR_NUMBER().
- ERROR_MESSAGE().
- ERROR_SEVERITY().
- ERROR_STATE().
- ERROR_PROCEDURE().
- ERROR_LINE()
Un problema de la utilización de RAISERROR, es que no es posible lanzar (o re-lanzar) un error del sistema desde el bloque CATCH. Esto es, si se produce un error dentro de nuestro bloque TRY, la ejecución se pasará al bloque CATCH, sin embargo, NO es posible desde el bloque CATCH re-lanzar el error original (ya que este intento, provocará un nuevo error ;-), por lo cual, como mucho podremos lanzar un error personalizado, he incluir en el texto del error la información que deseemos (es una ñapa, pero puede servir, no?).
La parte negativa (perdón... menos positiva) de la utilización de bloques TRY/CATH en código Transact-SQL de SQL Server 2005, es que no ofrece toda la potencia que sus equivalentes de lenguajes de programación como C#, como por ejemplo: sólo es posible especificar un único bloque CATCH, no existe el bloque FINALLY, y no es posible relanzar el error original desde el bloque CATCH.
También es importante recordar que si está activa la opción XACT_ABORT (es decir, SET XACT_ABORT ON) no será posible confirmar una transacción desde el bloque CATCH, evidentemente. Ante la duda, es posible consultar el valor actual de la función XACT_STATE(), y en función del mismo, poder tomar una u otra medida.
Errores definidos por el usuario (sp_addmessage)
Es posible definir errores de usuario con el fin de poder reutilizarlos, y así ofrecer un comportamiento homogéneo. Esto puede realizarse a través del procedimiento almacenado del sistema sp_addmessage (especificando código de error, severidad, texto del error, e idioma), y pueden consultarse los errores existentes en sys.messages (los errores de usuario se almacenan en MSDB). Los errores de usuario deben tener un código de error superior al 50000.
Una ventaja de la utilización de errores de usuario, es que es posible utilizar parámetros, de tal modo que el texto del error pueda variar en función de los parámetros del error. Otra ventaja, relacionada con la anterior, es el soporte multi-idioma, el cual no sólo permite especificar el mismo error en distintos idiomas, sino que además se puede especificar los parámetros en el orden deseado que se desea que aparezca en el texto del error (se debe tener en cuenta, que por las peculiaridades sintácticas de los distintos idiomas, los parámetros en el texto de error pueden no aparecer en el mismo orden para todos los idiomas).
Otra situación típica es la necesidad de registrar mensajes en el Visor de Sucesos de Windows, para lo cual, tenemos varias alternativas:
- Añadir el parámetro @with_log=’true’ al crear el mensaje de usuario con sp_addmessage.
- Añadir la opción WITH LOG al final de las sentencias RAISERROR.
- Ejecutar el procedimiento almacenado xp_logevent, el cual, no envía ningún mensaje al cliente, tan sólo se limita a escribir el mensaje en el Visor de Sucesos de Aplicación.
