Aquí hay parte de una plantilla de procedimiento almacenado que uso:
/* CREATE PROCEDURE... */
DECLARE
@ErrorMessage varchar(2000)
,@ErrorSeverity tinyint
,@ErrorState tinyint
/* Additional code */
BEGIN TRY
/* Your code here */
END TRY
BEGIN CATCH
SET @ErrorMessage = ERROR_MESSAGE()
SET @ErrorSeverity = ERROR_SEVERITY()
SET @ErrorState = ERROR_STATE()
RAISERROR(@ErrorMessage, @ErrorSeverity, @ErrorState)
BREAK
END CATCH
/* Further cleanup code */
Los bloques Try/Catch pueden ser complicados, pero son mucho más completos que @@error. Más importante aún, puede usar las diversas funciones error_xxx() dentro de ellos. Aquí almaceno el mensaje de error correcto en la variable @ErrorMessage, junto con suficientes otros datos para volver a generar el error. Desde aquí, cualquier cantidad de opciones están disponibles; puede hacer que @ErrorMessage sea una variable de salida, probar y manejar errores específicos, o crear sus propios mensajes de error (o ajustar los existentes para que sean más claros; puede irritarse al descubrir con qué frecuencia querrá hacer eso). Se presentarán otras opciones.
Algo a tener en cuenta:en algunas situaciones, SQL arrojará dos mensajes de error consecutivos... y error_message() solo detectará el último, que generalmente dice algo así como "falló el intento de crear el objeto", con el error real dado en el primer mensaje de error. Aquí es donde entra en juego la creación de su propio mensaje de error.
