I looked though Transient Fault Handling Framework code trying to address temporary loss of connectivity to SQL Server. There's one key point there: SqlException
is thrown both when there's an SQL-related problem (like syntax error) and something not related to SQL (like no connection).
Of course I need to try recover from the latter class problems only - if my code runs a malformed query I need to fail fast, not retry anything.
The framework tries to distinguish between those classes by examining SqlError.Number
and comparing it against a huge set of hardcoded values. That's lot of knowledge and code based on this strategy will definitely need maintenance once SQL Server internals change.
I thought maybe I can use SqlException.LineNumber
instead? According to MSDN, line numbering starts at 1 and line number 0 means the line number is not applicable so I guess that means the problem is not SQL related. I tried this for a while - whenever I have connectivity problems LineNumber
is always zero.
Is using SqlException.LineNumber
a good reliable way for identifying whether an exception is due to an SQL query problem or due to connectivity problem?