Seeking recommendation on using Exception Policy

Topics: Exception Handling Application Block
Nov 3, 2007 at 3:25 PM
Hi,

I have been using the EntLib for a while but never have discovered the recommended usage of the Exception Policy and is wondering if anyone can offer me some advice of this?

Should one use kind of fine grain exception policy approach? Exception Policy is based on exception type. So for example, SqlException. In a fine-grained approach in a DAL, should one have a policy for insertion, one for deletion, one for update and another for Query?

If one uses a coarse-grained approach with only one Exception policy for say "Data Access Policy", how could one dynamically changes the exception message to indicate whether the exception is caused by adding something or deleting something? How could we tune the exception message in such a coarse grain approach? How could we make the exception message more meaningful to the recipient. If all one gets is an InvalidOperationException ( "Your data causes an error" ), how could one work out if this is inserting duplicate primary key value or deleting primary key when there are candidate key or some database operations?

In the non-EntLib situation, one could throw InvalidOperationException() with situation specific message. How can I do this using EntLib? My reading on the specifying exception message tells me that they are bound by the policy.

So in this case to provide more meaningful exception message, one needs to have more specific exception policies. Is this correct?

Thanks.

Leon
Nov 5, 2007 at 11:34 AM
Hi Leon,

This looks like a perfect fit for Tom's great SQL Exception wrap handler (discussed in http://blogs.msdn.com/tomholl/archive/2007/08/01/mapping-sql-server-errors-to-net-exceptions-the-fun-way.aspx, available from http://codeplex.com/entlibcontrib). If you're not using SQL Server, you might want to code a similar handler for your DBMS of choice.

Regards,
Fernando
Nov 5, 2007 at 1:38 PM

This looks like a perfect fit for Tom's great SQL Exception wrap handler (discussed in http://blogs.msdn.com/tomholl/archive/2007/08/01/mapping-sql-server-errors-to-net-exceptions-the-fun-way.aspx, available from http://codeplex.com/entlibcontrib). If you're not using SQL Server, you might want to code a similar handler for your DBMS of choice.


Yes indeed, thanks for the recommendation. I guess with this, one could avoid exposing the database exception pass the DAL.

Leon
Nov 6, 2007 at 11:27 AM

fsimonazzi wrote:
Hi Leon,

This looks like a perfect fit for Tom's great SQL Exception wrap handler

Fernando,

On deeper investigation and reading the code, this will still have the original problem I posted when across tier. While Tom's creation is fantastic in mapping sub-error to application specific exception, it is nevertheless a Wrap Handler and this embedded the original exception as the inner exception of the newly throw one. So when crossing tier, the catcher needs the Sql Client assembly (or Oracle if I have rewrite this model on Tom's) on the catcher side. This is something I do not want.

So ideally we need a Replacement Handler that incorporate Tom's idea and this to me is probably far more useful.

Thanks for the pointer.
Nov 6, 2007 at 11:43 AM
Hi,

I think modifying Tom's handler to replace instead of wrap should be simple enough. You can get the original source code from the entlibcontrib site, and the wrapping/replacing behavior is available from EntLib's source code.

Fernando