Ответ.

Любое промышленное решение на SQL требует грамотной архитектуры обработки ошибок. Без логирования и акуратной обработки исключений невозможно отлаживать сложные процессы, особенно в хранимых процедурах и пакетных скриптах.

История вопроса: Стандартный SQL допускает минимальную обработку ошибок (например, RETURN и прекращение обработки). Современные расширения (T-SQL, PL/pgSQL, PL/SQL и др.) предоставляют полноценные конструкции обработки ошибок (TRY/CATCH, EXCEPTION).

Проблема: Без явной обработки ошибки "тонут", а администратору сложно установить причину сбоя — особенно при массовых изменениях или работе с внешними системами. Часто возникает задача логировать ошибки в отдельной таблице для последующего анализа.

Решение: Используйте арсенал TRY/CATCH (T-SQL) или EXCEPTION (PL/pgSQL), а также собственные таблицы логирования. Не забывайте отправлять диагностическую информацию (код ошибки, текст ошибки, параметры запроса и время) в лог.

Пример кода (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
        -- Бизнес-логика
        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

Пример кода (PL/pgSQL, PostgreSQL):

BEGIN
    -- Ваш код
EXCEPTION WHEN OTHERS THEN
    INSERT INTO error_log(ts, proc_name, err_text)
    VALUES(now(), 'my_proc', SQLERRM);
    RAISE;
END;

Ключевые особенности:

Мгновенный доступ к деталям сбоя для отладки.
Полная прослеживаемость по всем этапам процесса.
Не прерывайте выполнение без явного возврата и централизованного сбора лога.

Вопросы с подвохом.

Достаточно ли перехватить ошибку и завершить выполнение процедуры без передачи информации наружу?

Нет. Без явного логирования или распространения ошибки невозможно уловить и проанализировать причины сбоя. Важно либо детализировать ошибку в лог, либо как минимум пробрасывать её дальше (THROW/RAISE).

Можно ли использовать исключительно встроенные SQL Server/DBMS журналы для выявления всех ошибок в пользовательских процедурах?

Частично. Многие ошибки не попадают в серверные логи, если их "отловить" и обработать в приложении или в процедурах. Для бизнес-логики полезно вести свой лог событий с деталями.

Обязательно ли воспользоваться TRY/CATCH (или EXCEPTION), если в процедуре используются только простые DML-операции?

Обязательно, если процедура влияет на важные данные, участвует в критических цепочках и должна фиксировать нештатные ситуации. Даже "безопасные" операции могут привести к ошибке из-за внешних ограничений (уникальность, FOREIGN KEY, deadlocks и др).

Типовые ошибки и анти-паттерны

Не вести отдельный лог ошибок на уровне приложения.
Перехватывать ошибку, но не доводить информацию до пользователя/администратора.
Писать громоздкие блоки обработки без шаблонов — снижается читаемость.

Пример из жизни

Негативный кейс

В проекте ошибки не логируются, только отображаются пользователю. При массовом сбое администратор часами ищет "невидимую" проблему.

Плюсы:

Простое решение, меньше кода.

Минусы:

Диагностика невозможна.
Нет оснований для аудита и анализа качества данных.

Позитивный кейс

Любая критическая ошибка фиксируется в таблице-логе с деталями (время, процедура, параметры, код ошибки), и на неё ссылается тикет системы.