存储过程中的异常管理？

Question

我继承了一个具有大量存储过程的应用程序，其中许多应用程序都有异常处理代码，可以在错误表中插入一行并发送DBMail。我们在ASP.NET端有ELMAH，所以我想知道是否需要在存储的过程中进行异常管理。但在我把它拿出来之前，我想确保我不会因为对最佳实践的无知而犯一个严重的错误。

只有一个应用程序使用存储过程。

在Server 2005存储过程中使用异常管理比在ASP.NET端处理异常更合适吗？

Answer 1

如果有其他应用程序使用这些存储过程，那么在存储过程中保留错误处理可能是有意义的。在您的编辑中，您将指出情况并非如此，因此删除异常处理可能不是一个好主意。

在MSDN项目异常处理中，概述了何时捕获异常以及何时让它们在堆栈上冒泡。可以说，处理和记录存储过程中可恢复的数据库异常是有意义的。

Answer 2

有一个原则有时被称为“第一次故障数据捕获”--即。识别错误的第一个“代码块”的责任是立即捕获它以供将来诊断。在多层体系结构中，这导致了一些关于“第一”实际上是谁的有趣问题。

我认为存储过程将某些内容记录到db是非常合理的(发送电子邮件听起来有些过分，除了最批评的错误之外，但这是另一个问题)。它不能假设较高的层行为良好，您现在可能只有一个客户端，但您无法预测未来。

存储过程仍然可以抛出异常以及日志记录。有时候，在困难的情况下，能够将不同层次上的错误联系起来是非常方便的。

我需要很多说服才能删除错误日志记录。

Answer 3

我认为，登录到表只适用于更简单的系统，其中所有操作都是在单个存储过程调用中完成的。

一旦系统足够复杂，以至于您实现了跨数据库调用的事务，那么登录到存储过程中的数据库就成了一个更大的问题。

回滚撤销对表的日志记录。

在我看来，允许回滚和日志记录的逻辑会产生太多的缺陷。