Respuesta.

Cualquier solución industrial en SQL requiere una arquitectura adecuada de manejo de errores. Sin registro y un manejo cuidadoso de excepciones, es imposible depurar procesos complejos, especialmente en procedimientos almacenados y scripts por lotes.

Historia del problema: SQL estándar permite un manejo mínimo de errores (por ejemplo, RETURN y la interrupción del procesamiento). Las extensiones modernas (T-SQL, PL/pgSQL, PL/SQL, etc.) ofrecen construcciones de manejo de errores completas (TRY/CATCH, EXCEPTION).

Problema: Sin un manejo explícito de errores, "se hunden", y es difícil para el administrador determinar la causa del fallo, especialmente durante cambios masivos o al trabajar con sistemas externos. Frecuentemente surge la necesidad de registrar errores en una tabla separada para su posterior análisis.

Solución: Utilice el arsenal de TRY/CATCH (T-SQL) o EXCEPTION (PL/pgSQL), así como sus propias tablas de registro. No olvide enviar información de diagnóstico (código de error, texto de error, parámetros de consulta y hora) al registro.

Ejemplo de código (T-SQL, MS SQL Server):

CREATE TABLE ErrorLog (
    ErrorId INT IDENTITY PRIMARY KEY,
    ErrorTime DATETIME,
    ProcedureName NVARCHAR(128),
    ErrorMessage NVARCHAR(MAX),
    ErrorNumber INT,
    ErrorState INT,
    ErrorSeverity INT
);

CREATE PROCEDURE usp_ProcessOrders
AS
BEGIN
    BEGIN TRY
        -- Lógica empresarial
        UPDATE Orders SET Status = 'PROCESSED' WHERE Status = 'NEW';
    END TRY
    BEGIN CATCH
        INSERT INTO ErrorLog
        (
            ErrorTime, ProcedureName, ErrorMessage, ErrorNumber, ErrorState, ErrorSeverity
        )
        VALUES
        (
            GETDATE(),
            ERROR_PROCEDURE(),
            ERROR_MESSAGE(),
            ERROR_NUMBER(),
            ERROR_STATE(),
            ERROR_SEVERITY()
        );
        THROW;
    END CATCH
END

Ejemplo de código (PL/pgSQL, PostgreSQL):

BEGIN
    -- Su código
EXCEPTION WHEN OTHERS THEN
    INSERT INTO error_log(ts, proc_name, err_text)
    VALUES(now(), 'my_proc', SQLERRM);
    RAISE;
END;

Características clave:

Acceso instantáneo a los detalles del fallo para depuración.
Seguimiento completo en todas las etapas del proceso.
No interrumpa la ejecución sin un retorno explícito y recolección centralizada del registro.

Preguntas capciosas.

¿Es suficiente capturar el error y terminar la ejecución del procedimiento sin transmitir información al exterior?

No. Sin un registro explícito o difusión del error, no es posible captar y analizar las causas del fallo. Es importante detallar el error en el registro o al menos pasarlo adelante (THROW/RAISE).

¿Se pueden utilizar exclusivamente los registros integrados de SQL Server/DBMS para identificar todos los errores en procedimientos de usuario?

En parte. Muchos errores no llegan a los registros del servidor si se "capturan" y manejan en la aplicación o en los procedimientos. Para la lógica empresarial, es útil llevar su propio registro de eventos con detalles.

¿Es obligatorio utilizar TRY/CATCH (o EXCEPTION) si solo se utilizan operaciones DML simples en el procedimiento?

Es obligatorio si el procedimiento afecta datos importantes, participa en cadenas críticas y debe registrar situaciones anómalas. Incluso operaciones "seguras" pueden resultar en un error debido a restricciones externas (unicidad, FOREIGN KEY, deadlocks, etc.).

Errores comunes y anti-patrones

No mantener un registro de errores separado a nivel de aplicación.
Capturar el error, pero no transmitir la información al usuario/administrador.
Escribir bloques de manejo de errores voluminosos sin plantillas, lo que reduce la legibilidad.

Ejemplo de la vida real

Caso negativo

En el proyecto, los errores no se registran, solo se muestran al usuario. En caso de un fallo masivo, el administrador busca durante horas un problema "invisible".

Pros:

Solución simple, menos código.

Contras:

La diagnóstico es imposible.
No hay fundamentos para auditoría y análisis de calidad de datos.

Caso positivo

Cualquier error crítico se registra en una tabla de log con detalles (hora, procedimiento, parámetros, código de error), y se hace referencia a él desde un ticket del sistema.