SqlException.Number对SQL Server异常是否唯一？其使用安全性如何？

为什么开发者普遍用该数值判断SQL异常？ #

• 核心错误场景稳定：对于SQL Server原生的常见错误（如死锁1205、唯一键冲突2627），Number对应固定的内置错误码，含义明确且长期稳定，能快速定位问题类型，实现精准处理（比如死锁时自动重试）。
• 代码实现简洁可靠：对比解析异常消息文本，数值判断逻辑更简洁，也不会因消息的语言版本、格式更新而失效。
• 社区实践惯性：从早期的System.Data.SqlClient到现在的Microsoft.Data.SqlClient，该属性一直是处理SQL异常的标准方案，大量社区案例、文档都围绕它展开，开发者自然形成了使用习惯。

同一数值对应不同错误时，这种用法安全吗？ #

答案是并非绝对安全，风险源于错误码的多来源特性：

• 根据官方文档，Number的值可能来自三类：SQL Server内置错误码（来自master.dbo.sysmessages）、Win32系统错误码、客户端自定义错误值。不同来源的同一数值含义完全不同：
  • 错误码10054：作为Win32错误码时代表网络连接中断；但在SQL Server内置错误中，它表示列数据超出了提供程序的类型范围。
  • 错误码233：作为Win32错误码对应连接失败；但SQL Server内置错误中它表示目标列不允许为NULL。
• 仅依赖Number判断时，会出现跨场景误判，比如把网络连接错误当成数据校验错误处理，导致逻辑失效。

更安全的使用方式 #

• 结合SqlError.Class区分来源：SQL Server原生错误的Class（错误级别）通常在1-25之间，而Win32错误的Class一般为0或更高的异常值，可通过这个属性初步区分错误来源。
• 场景化精准判断：处理网络类错误时，除了Number，可辅助判断异常消息中的关键词（如"连接"、"网络"）；处理业务类错误时，优先参考官方文档明确的错误码范围。
• 避免全局通用判断：针对不同类型的异常（连接类、数据类、权限类）分别编写判断逻辑，不要用单一Number值覆盖所有场景。

内容的提问来源于stack exchange，提问作者Babangida