我在.NET 3.5应用程序的日志中得到SqlException，我正在寻找相应的数字（属性SqlException.Number的值）。
System.Data.SqlClient.SqlException: A transport-level error has occurred
when receiving results from the server. (provider: TCP Provider, error: 0
- The specified network name is no longer available.) at
System.Data.SqlClient.SqlConnection.OnError
我也遇到错误，例如：
System.Data.SqlClient.SqlException: A network-related or instance-specific error
occurred while establishing a connection to SQL Server. The server was not found
or was not accessible. Verify that the instance name is correct and that SQL Server
is configured to allow remote connections.
有谁知道如何正确捕捉这些例外情况？ （您也可以发布答案here）
答案 0 :(得分：5)
该特定错误不是来自SQL Server中的sys.messages - 因为它是连接的问题。所以我没有手数。
TBH，你应该做的最好的事情是确保将Number写入日志，但有例外 - 这样，你将始终在日志中并排显示数字和消息。可能无法回答你当前的问题，但这将是最好的前进恕我直言。不仅SqlException.Number而且SqlException.ErrorCode - 在这样的情况下，我认为.ErrorCode可能是您实际需要的（不确定而不检查）。
答案 1 :(得分：4)
您将找不到此关联的SQL错误编号 - 简单地说，发生错误是因为连接到服务器时出现问题。
由于代码无法连接到SQL Server，因此不会报告SQL错误。
关于SQLException.Number的MSDN文章：
This number corresponds to an entry in the master.dbo.sysmessages table.
对于没有关联的SQL错误号的异常，您可以使用将在异常对象的ErrorCode属性中的Windows HRESULT错误代码。
答案 2 :(得分：2)
伙计们，请在盲目地声称SqlException没有.Number之前检查实际的异常堆栈。只是某些MSDN页面有一个样板文本。 .ErrorCode通常获取一个通用值（由私有CTOR设置）。对于这个心室错误，你可以在这里看到异常堆栈：
如果你按照它，你会看到正在准备的代码填充了所有内容，但是在反射器中跟踪实际错误编号有点令人费解。
因此，无论谁看到下一个事情都会发布实际错误编号（或数字）。这些错误往往是非常罕见和短暂的，因为在服务器看到连接打嗝时，为了追逐他们的数字已经太晚了，所以有数字会很好。