从存储过程返回错误代码值是一种好习惯吗？答案

【问题标题】：Is returning an error code value from stored procedure good practice?从存储过程返回错误代码值是一种好习惯吗？
【发布时间】：2015-03-03 01:52:18
【问题描述】：

在我们公司，我们使用四种类型的简单存储过程（插入、更新、删除、选择）；数据库组坚持一个规则，即每个存储过程都应在更新/删除/插入存储过程类型的返回值中包含“错误代码”。

举例说明：

-------------------    
--INSERT sp example
-------------------
 INSERT INTO dbo.SomeTable(..) VALUES(...)

 if @@error <> 0
   return -1
 return 0

-------------------
--UPDATE sp example
-------------------
declare
@errsql int
@updcount int

update dbo.SomeTable set foo = @bar

select @errsql = @@error, @updcount = @@rowcount
if @errSQL <> 0     
  return -1
if @updcount < 1 
  return -2
return 0    

-------------------
--DELETE sp example
-------------------
delete from dbo.SomeTable where ...

if @@error <> 0
  return -1
return 0

这条规则可以追溯到我们使用旧 ASP/VB6.0 的年代；但是长期以来，我们的平台是纯 .NET 并且 SQL 端的错误（例如主键违规/唯一索引违规/等）作为 .NET 异常转移到应用程序，因此遵循这种模式似乎是一种货物崇拜编程（我可以看到检查更新行数在某些情况下可能很有用，但这仍然应该由应用程序开发人员而不是数据库组驱动 - 最后你必须检查应用程序中的返回代码才能产生任何效果:)。

所以我的问题是 - 你能看到这种做法有什么好处吗，还是这个经典的货物崇拜编程示例？

【问题讨论】：

有趣的是，目标似乎是用常数替换可能有用的错误值。并且没有使用 try/catch。或其他有用的输出，例如在大多数情况下，您可能希望大于零的已删除行数。我更喜欢使用RaIsError 来提供有用的诊断信息。（我们要不要凑钱给微软买一个元音？）
你为什么不用RAISERROR？
@SriramSakthivel - 这不是关于如何从 SQL 向 .NET 抛出异常，而是关于规则“除了 select 之外的每个存储过程都应该返回错误代码”及其有效性
这不是错误处理。它更像是错误抑制。您的代码会为任何错误返回 -1。当你在任何地方都没有关于实际发生的事情的任何信息时，你如何调试这种事情？对于基本的 CRUD 操作，我更喜欢在 sql 端不使用错误处理，让应用程序正确处理出现问题时从 sql 返回的异常。

标签： c# sql-server

【解决方案1】：

如果您在项目的其余部分使用异常，我想说异常应该是要走的路。请注意，您有 RAISEERROR (http://msdn.microsoft.com/en-us/library/ms178592.aspx) SQL 子句，因此您可以在这些存储过程中引发异常。

我认为 RAISEERROR 的严重性必须超过 16 才能将其作为异常引发（您可能需要检查 http://msdn.microsoft.com/en-us/library/ms164086.aspx）。对TRY/CATCH SQL 块起作用的任何错误都应该引发异常。

【讨论】：