Question

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

举例说明：

-------------------    
--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异常转移到应用程序，因此遵循这种模式似乎是货物崇拜编程（我可以看到检查更新行数在某些情况下是有用的，仍然应该由应用程序开发人员驱动，而不是由数据库组驱动 - 最后你必须检查应用程序中的返回代码才能产生任何效果：）。

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

Answer 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块上可能有效的任何错误，异常应该会增加。

从存储过程的良好实践返回错误代码值？

1 个答案: