gbn*_*gbn 6 t-sql stored-procedures sql-server-2005 exception sql-server-2008
我们是一个SQL Server数据库开发人员团队.我们的客户是C#/ ASP.NET,C#和Java Web服务,Java/Unix服务和一些Excel的混合包.
我们的客户端开发人员只使用我们提供的存储过程,我们希望(当然,合理的)他们将它们视为Web服务方法.
我们的一些客户端开发人员不喜欢SQL异常.他们用他们的语言理解他们,但他们不理解SQL在如何沟通问题方面受到限制.
我不只是指SQL错误,例如尝试将"bob"插入int列.
我还指的是例外,例如告诉他们参考值是错误的,或者数据已经改变,或者他们不能这样做,因为他的聚合不是零.
他们没有任何具体的替代方案:他们提到我们应该输出参数,但我们假设一个例外意味着"处理停止/回滚.
人们如何处理数据库 - 客户合同？通常或DB和客户端代码猴之间存在分离的地方.
编辑:
嗯，我是一个经常与数据库打交道的客户端代码猴子。我是这样处理的。
SQL 中发生的异常（引发错误）会传播回调用者。这将包括引用约束、唯一索引违规、更严重的问题等。基本上，任何不会使数据操作正常发生的事情都应该被传播回去。
调用者 C# 应该具有以下内容：
catch (SQLException sqlEx)
然后根据需要处理异常。它们应该有一个特定的 SQLException 处理程序。这个很重要。
我通常远离输出参数，因为我认为这些参数与正在传输的数据相关，而不是任何错误消息，此外，我可以检查 SQL Server 错误代码的异常，因此我们需要的所有数据都应该在该异常中。
此外，在某些情况下，使用 SQL Server，我们的存储过程可能会引发“业务类型的异常”。在这些情况下，我们添加自定义错误号（50000 以上），并在需要时在存储过程中引发该错误。一般来说，我们会尽量将这些保持在最低限度，因为这会增加复杂性，但在某些情况下，我们发现它们是必要的。
现在，由于客户端正在捕获 SQLException，因此他们可以查看 SQL Server 在异常中返回的错误代码，然后在捕获异常且错误号为某个值时采取任何特殊操作（如果需要）。如果自定义错误（> 50000）需要的话，这允许基于错误代码进行二级错误处理。
这还允许 DBA 引发自定义错误，并使客户端代码有一致的方式来处理它们。然后，DBA 必须告诉客户端代码猴子自定义错误是什么，以便他们可以做好准备。
我通常不会将返回代码用于错误处理目的，尽管我可以看到如何使用它们，但这意味着代码猴子层中有更多逻辑来查看和处理返回代码。如果它们是一个问题，我想要一个例外，因为这样我就可以一致地处理它们。如果我还必须查看返回码，那么现在有多种错误处理途径。