英文:
Why use different error numbers for THROW?
问题
我正在使用存储过程将数据插入表中，并首先检查数据是否有效。如果无效，我会使用 throw 抛出一个错误：
;THROW 50000, @Msg, 1;
规格说明 表明错误号必须在 50000 到 2147483647 之间（包括两者）。我是否可以为所有 throw 的错误都使用 50000，有没有什么特别的原因？
通常情况下，我的代码会将任何 SQL 错误视为集成错误，或者我会检查错误消息的文本。我是否看不到一些关于编号的最佳实践？
如果相关的话，我的代码是用 VB.NET 写的，但我认为它应该适用于任何程序。
英文:
I'm using a stored procedure to insert into a table, and first checking to be sure the data is valid. If it isn't, I'm using throw to throw an error:
;THROW 50000, @Msg, 1;
The specifications say the error number must be between 50000 and 2147483647 (inclusive). Is there some reason I shouldn't just use 50000 for all of errors I throw?
My code would generally consider any SQL errors to be integration errors, or I would check the text of the error message. Is there some best practice for numbering I can't see?
If it's relevant, my code is in VB.NET, but I imagine it should apply to any program.
答案1
得分: 2
请注意，不是每次引发错误都是因为数据无效。在存储过程中，有许多情况下您可能会明确选择引发错误。
与错误相关联的主要目的是为了对错误进行分类分组。考虑以下潜在的错误类别：
50000 - 无效数据
50001 - 存储过程今天已执行过（用于每日作业）
50002 - 超时
50003 - 引用完整性冲突
...
仅因为您可能只为特定的错误类别引发错误，并不意味着SQL服务器只能支持一个错误类别。开发人员可以自由地提出任意数量的错误类别（在50000-2147483647的限制内）。
还值得注意的是，@Msg 可能在某些情况下不足够提供足够的信息。您提供的代码是通用的，因此我们不知道 @Msg 是什么，但它可能除了错误类别之外还有其他具体信息，例如，“为什么将数据插入此表时无效？” 因此，在同一个存储过程中引发的不同错误可能会有不同的 @Msg，这使得在错误日志中进行操作并执行诸如汇总最常出现的错误等操作变得非常困难。
您可以在应用程序中使用任何错误编号约定，但开发人员选择不使用50000来引发所有错误的原因有很多。其中一个主要考虑因素是使用不同的错误代码对错误进行分类。从那里，可以执行各种操作，从推动额外的业务逻辑到汇总错误日志等等。
英文:
> I'm using a stored procedure to insert into a table, and first checking to be sure the data is valid. If it isn't, I'm using throw to throw an error
The first thing to consider is that not every instance of throwing an error is because of invalid data. In a stored procedure, there are many scenarios where you may decide to throw an error explicitly.
The primary point of associating number codes with errors is for categorizing errors. Consider the following potential error categories:
50000 - Invalid data
50001 - Stored Procedure Already Executed Today (for daily jobs)
50002 - Timeout
50003 - Referential Integrity Conflict
...
Just because you may only be throwing an error for a specific error category doesn't mean SQL servers should only support a single category of errors. Developers are free to come up with as many error categories as they wish (within the constraints of 50000-2147483647).
Also worth noting is that @Msg may not be enough information in some cases. The code you've provided is generic so we don't know what @Msg is, but it could have specifics beyond the error category, such as "What about the data was invalid for inserting into this table?" Because of this, the @Msg may be different for various errors thrown within the same stored procedure. That makes it very difficult to go through error logs and do things such as aggregate the most commonly occurring errors.
You are free to use whatever error number convention you wish within your application. However, there are many reasons why developers may choose to not use 50000 for all of the errors they throw. One of the main considerations for using different error codes is to classify errors by category. From there, anything from driving additional business logic or aggregating error logs and more can be performed.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论