Ответ.

Обработка ошибок и организация логирования в SQL приобрели особую популярность с развитием сложных бизнес-процессов, когда стало важно не просто останавливать выполнение при ошибке, а фиксировать факт сбоя и, по возможности, продолжать работу. Изначально SQL не имел развитых средств try-catch, а каждая СУБД предлагала свои механизмы.

История вопроса:

Ранние версии SQL стандартов не имели встроенных операторов для ловли ошибок в процедурах. Позднее производители стали внедрять конструкции, такие как TRY...CATCH в Microsoft SQL Server, или HANDLER в MySQL, позволяя более гибко контролировать рабочий процесс прямо на уровне БД.

Проблема:

Ошибки могут возникать как вследствие некорректных данных, так и из-за системных причин. Если в хранимой процедуре не реализован захват и запись ошибок, отладка и сопровождение становятся крайне затруднительными. Кроме того, необходимо уметь различать критичные ошибки и обработанные, чтобы не прерывать выполнение бизнес-операции там, где это не требуется.

Решение:

В современных системах следует внедрять конструкции сбора и логирования ошибок. Необходимо создавать отдельные лог-таблицы, использовать TRY...CATCH (SQL Server) или DECLARE ... HANDLER (MySQL), сохранять детальную информацию об исключениях, чтобы потом анализировать причины сбоев.

Пример кода (SQL Server):

CREATE PROCEDURE dbo.UpdateCustomer
  @CustomerID INT,
  @NewName NVARCHAR(100)
AS
BEGIN
  BEGIN TRY
    UPDATE Customers SET Name = @NewName WHERE CustomerID = @CustomerID;
  END TRY
  BEGIN CATCH
    INSERT INTO ErrorLog (ErrorMessage, ErrorSeverity, ErrorTime)
    VALUES (ERROR_MESSAGE(), ERROR_SEVERITY(), GETDATE());
    THROW;
  END CATCH
END;

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

• Использование TRY...CATCH позволяет изолировать потенциально опасный код.
• Вставка ошибок в лог-таблицу с максимальной детализацией.
• Throw/Error raising для корректного завершения процедуры и передачи информации вызывающему слою.

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

Все ли типы ошибок можно поймать внутри блока TRY...CATCH (или через handler)?

Нет, не все ошибки, например, грубые сбои сервера, могут быть перехвачены. Ошибки типа "Attention," или сбой соединения, выходят за пределы transacton обработки.

Что произойдёт с незакоммиченными изменениями в процедуре при ошибке, если не использовать транзакцию?

Изменения будут частично зафиксированы, часть обновлений войдёт в базу, а часть может быть потеряна. Для избегания неконсистентности рекомендуется всегда использовать транзакции.

BEGIN TRY
  BEGIN TRANSACTION;
  --...код
  COMMIT;
END TRY
BEGIN CATCH
  ROLLBACK;
END CATCH

Можно ли использовать INSERT EXEC прямо из блока CATCH, чтобы записать ошибку из другого контекста?

Не всегда: INSERT EXEC запрещён в ряде контекстов (например, если уже есть активная транзакция), поэтому это может вызвать ошибки второго уровня. Лучше собирать детали ошибки локально и потом записывать их одиночным INSERT.

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

• Отсутствие журналирования ошибок.
• Игнорирование TRANSACTION, что приводит к разрыву данных.
• Логирование только текстов, без кодов ошибок и времени/кода пользователя.

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

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

Клиент реализовал логику только через RAISERROR без логирования, поэтому ошибки не сохранялись и не анализировались.

Плюсы:

• Меньше кода.

Минусы:

• Нет возможности понять причину сбоев, анализировать проблемы в продакшене невозможно.

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

Использован TRY...CATCH плюс таблица ErrorLog, фиксация времени, кода ошибки, пользователя, текста и трассировки.

Плюсы:

• Лёгкая аналитика ошибок.
• Быстрая локализация проблем.
• Прозрачность для бизнес-аналитиков.

Минусы:

• Требует поддерживать логи, иногда чистить их для оптимизации.