Returning a Different Type of Exception From DataPortal_OnDataPortalException

grahamm posted on Friday, August 08, 2008

Hi,

we're currently looking at implementing some exception handling at the server-side in order to wrap or replace certain exceptions (such as SQL specific exceptions) with more user-friendly exceptions.  In order to achieve this we've been looking at using the Exception Management block in the Enterprise Library which allows you to define "policies" which map exception types to handling mechanisms such as replacing the exception with a different exception, wrapping the exception in a new exception, logging the exception or even performing custom actions such as the ability to email the exception to the sys admin.

 

The most obvious hook point that we've found is in our base classes' DataPortal_OnDataPortalException method - we're passed the exception so we then pass it onto the Exception Management block.  But, if we've defined a policy for the exception that wraps or replaces the exception, there's no way of getting this new exception type back to the DataPortal to be thrown back to the client as the return type of  DataPortal_OnDataPortalException is void and the parameter to the method is not passed by ref. 

 

At the moment we've modified the framework to pass the exception by reference but obviously we'd prefer not to have to do this.  So are we doing something unique here or are others out there handling this requirement differently?  Obviously it would be great if the framework could incorporate this use case but I realise that a single request for a framework enhancement does not have much weighting.

 

Thanks in advance,

Graham

FrankM replied on Friday, August 08, 2008

We made the same modification to allow server throwing exception to use wcfLogBook created by Juval Lowy. It would be nice if there is a 'switch' to turn on and off of this server exception wrapping operation.

alef replied on Thursday, December 11, 2008

Maybe you can override DataPortal_OnDataPortalInvokeComplete.
On the UI you will still have a DataPortalException, but the InnerException will be the one you have created.


    protected override void DataPortal_OnDataPortalInvokeComplete(DataPortalEventArgs e)
    {
          call your translation method eg TranslateException
     
    }

/// <summary>

/// Translate a SqlException to the correct DALException

/// </summary>

/// <param name="ex">SqlException to be translated</param>

/// <returns>An DALException</returns>

protected Exception TranslateException(SqlException ex) {

Exception dalException = null;

// Return the first Custom exception thrown by a RAISERROR

foreach (SqlError error in ex.Errors) {

if (error.Number >= 50000) {

dalException = new DalException(error.Message, ex);

}

}

if (dalException == null) {

// uses SQLServer 2000 ErrorCodes

switch (ex.Number) {

case 17:

// SQL Server does not exist or access denied.

case 4060:

// Invalid Database

case 18456:

// Login Failed

dalException = new DalLoginException(ex.Message, ex);

break;

case 547:

// ForeignKey Violation

dalException = new DalForeignKeyException(ex.Message, ex);

break;

case 1205:

// DeadLock Victim

dalException = new DalDeadLockException(ex.Message, ex);

break;

case 2627:

case 2601:

// Unique Index/Constriant Violation

dalException = new DalUniqueConstraintException(ex.Message, ex);

break;

default:

// throw a general DAL Exception

dalException = new DalException(ex.Message, ex);

break;

}

}

// return the error

return dalException;

}