Share via

Exceptions in ADO.Net 2.0 [Siraj Lala]

  • Article

I’d like to briefly talk about some of the work we have done in ADO.NET 2.0, for improvement of Errors and Exception usage. In ADO.NET 1.1, several error messages were generic and didn’t have enough detail to make them actionable. An example of this is the infamous “General network error” that could occur in variety of cases. In ADO.NET 2.0, we now surface the exceptions that we get when making calls to the lower network layer (SNIX – the network transport layer used by SqlClient). These exceptions are encapsulated in the exception thrown by SqlClient, with additional information at the API level.

From the implementation perspective, the errors coming from SNIX are wrapped in a Sqlclient level message that describes the task SqlClient was trying to perform when this error occurred. The result being that the SNIX message is included in the SqlClient-level message. The general syntax we used is:
<sqlclient message> (provider:<SNIX provider>, error: <SNIX error code> - <SNIX error message>)

This did make the error messages more verbose, but it also made them much more meaningful and actionable. Let me illustrate this with an example. Let’s say you force encryption from the client-side (encrypt=true) but the client was not able to validate the servers certificate.
In ADO.NET 1.1 this would have resulted in an exception message – “SSL Security Error.”
The same scenario in ADO.NET 2.0 gives the error message - “A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 0 - A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.)”.

Here’s another example. Let’s say the application loses network connectivity while its reading results from a SqlDataReader.
In ADO.NET 1.1 this would have resulted in an exception message – “General network error. Check your network documentation.”
This same scenario in ADO.NET 2.0 gives the error message – “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.)”.

I also wanted to make a brief mention of a new Exception base class we added in .NET 2.0 – System.Data.Common.DbException. This was added to enable catching provider exceptions in a generic way, when writing provider agnostic code . We made the provider specific exceptions (i.e SqlException, OracleException, OleDbException, OdbcException) derive from DbException. Hence, if you are writing provider-agnostic code, you can catch DbException if all you are interested in catching are the provider specific exceptions.

Siraj Lala
Test Lead - ADO.Net team

Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights

Comments

  • Anonymous
    June 09, 2005
    Fantastic, I have given this decent coverage in my book (chapter #2) regards the new exception structure and enhancements in ADO.NET 2.0.

    The new inheritance model is incredibly useful.

    I have a question - would you say that it is maybe too bold to make the following statement?

    "DbException deals with all exceptions that generate out of disconnected data cache or provider independent code?"

  • Anonymous
    June 09, 2005
    Hi Sahil, Its nice to know that this would be covered in your book.
    With regards to your question, DbException will not help for exceptions coming out of disconnected data cache (like DBConcurrencyException). These will have to handled separately. Only the provider specific derive from DbException(base). Hope that helps.

    -Sushil Chordia[MS]

  • Anonymous
    June 12, 2005
    The comment has been removed

  • Anonymous
    June 13, 2005
    Hi Sahil. No, we cannot make that statement. When working with a disconnected Data cache you may get various exceptions that will not be caught if only catching DataException. An example is exceptions got when calling RealXmlSchema.

    Thx.
    siraj.

  • Anonymous
    June 13, 2005
    Ok can we say "System.Data.DataException deals with exceptions coming out of Disconnected data?"

    I am trying to categorize the exceptions for easy understanding .. thats all :)

  • Anonymous
    June 14, 2005
    The comment has been removed

  • Anonymous
    June 15, 2005
    All hail the death of the GNE!

  • Anonymous
    June 29, 2005
    Fantastic. Thank you Siraj, this sounds perfect. :-)

  • Anonymous
    January 01, 2008
    PingBack from http://movies.247blogging.info/?p=3706

  • Anonymous
    January 21, 2009
    PingBack from http://www.keyongtech.com/447522-sql-server-connection-irritations-again