我继承了一个具有很多存储过程的应用程序，其中许多具有异常处理代码，可在错误表中插入一行并发送 DBMail。我们在 ASP.NET 端有 ELMAH，所以我想知道存储过程中的异常管理是否必要。但在我撕掉它之前，我想确保我不会因为对最佳实践的无知而犯下严重错误。
只有一个应用程序使用存储过程。
与在 ASP.NET 端处理异常相比，何时更愿意在 SQL Server 2005 存储过程中使用异常管理？
【问题讨论】：
标签： asp.net sql-server stored-procedures exception-handling
我相信记录到表只适用于更简单的系统，其中所有操作都在单个存储过程调用中完成。
一旦系统足够复杂，您可以跨数据库调用实现事务，那么在存储过程中记录到数据库就会成为一个更大的问题。
回滚会撤消对表的日志记录。
在我看来，允许回滚和日志记录的逻辑会产生太多潜在的缺陷。
【讨论】：
有一个原则有时被称为“首次故障数据捕获” - 即。第一个“代码块”负责识别错误以立即捕获它以供将来诊断。在多层架构中，这会引发一些有趣的问题，即究竟谁是“第一”。
我相信存储过程将某些内容记录到数据库是非常合理的（发送电子邮件对于除了最关键的错误之外的所有人来说听起来有些矫枉过正，但这是另一个问题）。它不能假设更高层会表现良好，您现在可能只有一个客户端，但您无法预测未来。
存储过程仍然可以引发异常以及日志记录。有时在困难的情况下能够关联不同层中的错误实际上非常方便。
我会花很多时间说服来删除错误记录。
【讨论】：
如果有其他应用程序使用这些存储过程，那么在存储过程中保留错误处理可能是有意义的。在您的编辑中，您指出情况并非如此，因此删除异常处理可能不是一个坏主意。
在MSDN article Exception Handling 中概述了何时捕获异常以及何时让它们在堆栈中冒泡。可以说，处理和记录可从存储过程中恢复的数据库异常是有意义的。
【讨论】：