我看了Transient Fault Handling Framework代码，试图解决temporary loss of connectivity to SQL Server。这里有一个关键点：当存在与SQL有关的问题（例如语法错误）和与SQL不相关的问题（例如无连接）时，都会抛出SqlException。
当然，我只需要尝试从后面的类问题中恢复-如果我的代码运行格式错误的查询，则我需要快速失败，而不重试任何内容。
该框架通过检查SqlError.Number并将其与大量的硬编码值进行比较，从而试图区分这些类。一旦SQL Server内部发生变化，基于此策略的大量知识和代码肯定将需要维护。
我以为也许可以改用SqlException.LineNumber？根据MSDN，行号从1开始，行号0表示该行号不适用，因此我认为这与SQL不相关。我尝试了一段时间-每当遇到连接问题时LineNumber始终为零。
使用SqlException.LineNumber是一种确定异常是否是由于SQL查询问题还是由于连接问题的可靠方法吗？
最佳答案
我认为您不能可靠地使用LineNumber属性作为异常是与连接有关的错误的指示器。当在存储过程，触发器或函数期间发生错误时，将设置LineNumber。但是，在这些项目之外的查询中甚至在视图中仍然可能会出错，甚至可能导致LineNumber为0的SqlException。最好的方法是将您使用Number属性描述的技术与一组硬编码值进行比较。