Improving ADO exception management in NHibernate

When you working with NHibernate you may need to manage some specific situation where an exception is thrown by the RDBMS/DataProvider. For example you may need to do something specific for a “constraint violation”, to manage a “deleted object” or a stale-object-state but generated by RDBMS (because isolation level for example).. and so on.

All those ADO.NET exceptions are catch and wrapped, in NHibernate, by a GenericADOException. NHibernate can’t manage each situation and re-throw a specific exception because the System.Data.Common.DbException does not have enough information to do it. Each DataProvider, in general, inherits its specific exception from DbException and adds some information to allow the recognition of the cause.

To allow you the management of each situation according with your RDBMS NH has : ISQLExceptionConverter.

To instruct NH in order to use your own implementation of ISQLExceptionConverter the corresponding configuration is:

<property name="sql_exception_converter">NameSpace.YourImpl, AssemblyName</property>

or, through programatic configuration :

conf.SetProperty(Environment.SqlExceptionConverter,typeof(YourImpl).AssemblyQualifiedName);

Before show an implementation of ISQLExceptionConverter there is another useful method to know:

ADOExceptionHelper.ExtractDbException(Exception sqlException)

The method extract the first System.Data.Common.DbException from a given sqlException tree (the exception itself and its inner exceptions).

Now an example of ISQLExceptionConverter for MsSQL:

public class MsSqlExceptionConverterExample : ISQLExceptionConverter
{
  public Exception Convert(AdoExceptionContextInfo exInfo)
  {
      var sqle = ADOExceptionHelper.ExtractDbException(exInfo.SqlException) as SqlException;
      if(sqle != null)
      {
          switch (sqle.Number)
          {
              case 547:
                  return new ConstraintViolationException(exInfo.Message,
                      sqle.InnerException, exInfo.Sql, null);
              case 208:
                  return new SQLGrammarException(exInfo.Message,
                      sqle.InnerException, exInfo.Sql);
              case 3960:
                  return new StaleObjectStateException(exInfo.EntityName, exInfo.EntityId);
          }
      }
      return SQLStateConverter.HandledNonSpecificException(exInfo.SqlException,
          exInfo.Message, exInfo.Sql);
  }
}

• 547 is the exception number for constraint conflict.
• 208 is the exception number for an invalid object name in the SQL.
• 3960 is the exception number for Snapshot isolation transaction aborted due to update conflict.

As you can see you can re-throw your own Exception for each situation and then capture and manage it in a high application level.

Again… Enjoy NHibernate injectability.