回答。

SQL中的错误处理和日志管理在复杂业务流程发展中变得尤为重要，当单纯停下执行错误时已经不再充分，而是需要记录故障并在可能的情况下继续工作。最初，SQL没有发展的try-catch机制，每个数据库管理系统提供了自己的机制。

问题的历史：

早期SQL标准版本没有内置的捕获错误的操作符。后来，制造商开始引入结构，例如Microsoft SQL Server中的TRY...CATCH或MySQL中的HANDLER，使得在数据库层面上可以更灵活地控制工作流程。

问题：

错误可能由于不正确的数据或系统原因而发生。如果在存储过程中没有实现捕获和记录错误的机制，调试和维护将非常困难。此外，必须能够区分关键错误和已处理的错误，以免在不需要的地方中断业务操作。

解决方案：

在现代系统中，应该引入错误收集和日志记录的结构。需要创建单独的日志表，使用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"类型的错误或连接故障超出了事务处理的范围。

如果不使用事务，过程中的未提交更改在错误发生时会怎样？

更改会部分提交，部分更新将写入数据库，而部分可能会丢失。为了避免不一致性，建议始终使用事务。

BEGIN TRY
  BEGIN TRANSACTION;
  --...代码
  COMMIT;
END TRY
BEGIN CATCH
  ROLLBACK;
END CATCH

可以直接从CATCH块使用INSERT EXEC将错误记录到另一个上下文吗？

并不总是可以：INSERT EXEC在某些上下文中被禁止（例如，如果已经有一个活动的事务），因此可能会导致第二级错误。最好在本地收集错误细节，然后单独插入记录。

常见错误和反模式

缺少错误日志记录。
忽视TRANSACTION，导致数据断裂。
仅记录文本，没有错误代码和时间/用户代码。

生活中的实例

负面案例

客户仅通过RAISERROR实现了逻辑，没有日志记录，因此错误未保存和分析。

优点：

代码更少。

缺点：

无法了解故障原因，无法分析生产中的问题。

正面案例

使用了TRY...CATCH和ErrorLog表，记录时间、错误代码、用户、文本和跟踪。