Asp.net -best地方陷阱SQL服务器的SQL错误

Question

对于Asp.net Web应用程序，它是最好的：SQL存储过程和测试代码或返回值内

1. 捕获错误
2. 只是让错误发生在SQL（不处理它），并依靠ado.net引发代码中的错误。

这里有什么最佳实践？

Answer 1

此处适用的一般规则是尽可能将错误尽可能接近源。 SQL Server现在有“try ... catch ...”错误捕获语法。所以使用它。额外代码的一小部分开销是微不足道的，如果在SP中有多个语句，则可以调整RAISERROR中的字符串以帮助本地化问题。

在界面中，捕获SP错误事件并处理它，应用程序代码中处理其他错误陷阱的方式应该不难。

这是存储过程中最被忽视的“最佳实践”之一，它比“常规”代码更重要，因为使用step = through调试器会更复杂。

一个有用的模式是在你的SP中处理它，就像你期望它在任何其他不透明的SDK库中处理一样。

Answer 2

我使用try/catch对库或包括数据库查询在内的其他服务器生成调用的所有潜在错误。我主要是一个开发人员而不是DBA，所以我用我最熟练的语言来处理错误，而不是SQL。我相信每个程序员都会有所不同。在我的书中没有处理错误是不好的。

Answer 3

我更喜欢这两个 -

• 存储过程调用RAISEERROR，它表现为在ADO.NET异常
• 存储过程返回错误代码，如果一个存储过程的调用另一个

一般

，我总是做一个try-catch

Answer 4

根据本article内部数据库调用，这是一种“愚蠢的“例外 - 即如果SP发生错误，这意味着SP或数据本身出现问题。

我的建议是将错误捕获到aps.net中，因为您有更多的记录错误的可能性以及为了调查问题而传递给SP的所有参数。

Answer 5

数据层中最可能的故障模式是错误的用户输入值，例如请求不存在的记录。大多数其他错误都是由代码损坏引起的，通常在测试时立即被捕获。我喜欢捕获数据库错误，并且总是抛出一个自定义错误，提供关于请求数据和上下文的更多信息。然后这个错误会回调调用堆栈，如果这是一个用户可纠正的错误，我可以提醒他们注意这个事实。否则当错误到达堆栈顶部时，应用程序的中央错误页面处理程序将被调用。最糟糕的事情是要抓住一个错误，不要让它回暖。返回代码是过时的构造，除非与COM组件或外部系统交谈。

Answer 6

理想情况下，您的Web应用程序不知道后端或数据访问。所以它不应该处理与sql相关的错误 - 这些错误应该由数据访问层处理。但是，Web应用程序需要通过向最终用户提供友好的消息来优雅地处理失败。

Answer 7

我会说这取决于你在存储过程中所做的事情以及你想要对发生的某些错误做什么。有时我会在sp中处理它，但有时我会让它升到数据层代码。请记住，有时您可能会错过使用sql server 2005 try/catch时发生的错误，请参阅my post。而在代码中（我的例子是C＃），你可以访问SqlErrorCollection对象中的所有错误。

只要确定你在存储过程中的错误处理是经过深思熟虑的，任何不确定性都留给数据层代码，你必须记录下所有的东西。

Answer 8

答案是你需要两个都做。一些错误实际上是从数据库引擎下行触发的。当然，它们的来源根据您连接数据库的实际方式（OLBC，OLEDB等）而有所不同。你必须找到解决这些问题的方法。一些错误，例如死锁错误也将在应用程序级别处理。

除了错误之外，接收和处理来自SQL Server数据库引擎的消息也是一个好主意。这些与错误非常相似，可以为应用程序提供大量有用的诊断信息。如果您使用的是System.Data.SQLClient，则需要创建一个SqlInfoMessageEventHandler委托，标识处理该事件的方法以侦听SqlConnection类上的InfoMessage事件。您会发现诸如严重性和状态的消息上下文信息作为参数传递给回调函数，因为从系统角度来看，这些消息就像错误一样。 我希望这有助于！