Mapping SQL Server Errors to .NET Exceptions (the fun way!)

re: Mapping SQL Server Errors to .NET Exceptions (the fun way!)

Peter Ritchie — Wed, 01 Aug 2007 14:39:19 GMT

Not to mention having to write all the individual exception classes to handle Number being 1 to 21999+. This is a corner exception handing case where the standard exception handling practices become a hindrance, obviously it would not be good to have 21000+ individual exception classes.

One of the wonderful things about exception handling is the ability to rethrow new exceptions. If an exception can't be handled but the code that caught the exception can add value to it because of it's context, one useful tool is to rethrow a new exception. I don't really see that possibility here (except to throw a different exception from HandleException, which doesn't smell right). I think the ability to get a new exception from HandleException (or TryHandleException) that the catch block could re-throw or do something with (since HandleException is an abstraction) could prove useful.

re: Mapping SQL Server Errors to .NET Exceptions (the fun way!)

tomholl — Wed, 01 Aug 2007 14:47:40 GMT

Peter - this example is all about throwing new exceptions. The Exception Handling Application Block can be configured to do any of the following actions after executing the exception handling pipeline:

- Swallow exceptions (HandleException returns false)

- Notify that the original exception should be rethrown (HandleException returns true)

- Throw the exception coming out of the pipeline (This happens inside HandleException so nothing is returned).

When using the SqlExceptionWrapHandler (or the built-in WrapHandler and ReplaceHandler), the only option that makes sense is to throw the new exception.

Also I agree you wouldn't want to create 21,000 exception classes, but this solution doesn't require you to do so. In most situations there are only a handful of error codes that you will likely justify a new exception type, since, as you mentioned the whole point here is to add context that a higher layer might be able to deal with - and there is a good chance that 99% of possible SQL errors won't be dealt with individually.

re: Mapping SQL Server Errors to .NET Exceptions (the fun way!)

tomholl — Wed, 01 Aug 2007 14:51:34 GMT

I forgot to mention that from EntLib 3.0, there is a new overload to ExceptionPolicy.HandleException that returns the exception coming out of the pipeline as an out parameter, rather than automatically throwing it. I think this is exactly what you suggested Peter.

re: Mapping SQL Server Errors to .NET Exceptions (the fun way!)

Peter Ritchie — Wed, 01 Aug 2007 20:45:40 GMT

Tom, yes the ExceptionPolicy.HandleException overload seems to be exactly what I was talking about...

With regard to 21000 exception classes; I was basically agreeing that the finally exception handling code in your blog is necessary. It's effectively impossible to write 21000 exception classes to make to each of the SQL Server error codes. But, in the general case it's preferred to have a error-condition-to-exception mapping.

re: Mapping SQL Server Errors to .NET Exceptions (the fun way!)

Alex — Fri, 03 Aug 2007 11:53:25 GMT

But if we use [ExceptionCallHandler]? How could we capture the error messages and present under the Web Pages?

We still need to try.. catch to make it work if we really want to show that error message in the web page.

Is this true?

re: Mapping SQL Server Errors to .NET Exceptions (the fun way!)

tomholl — Sat, 04 Aug 2007 09:33:39 GMT

Alex - the solution described in this post is about wrapping SqlExceptions into more meaningful .NET exceptions as they leave the data access layer. In order to display messages to users in an ASP.NET application, you'd most likely want to use a standard try... catch approach.

re: Mapping SQL Server Errors to .NET Exceptions (the fun way!)

Herbjörn Wilhelmsen — Mon, 13 Aug 2007 17:07:19 GMT

Hi,

I would appreciate it if the ErrorCode in the handlers configuration could contain a comma separated list of values like:

547,2601,2602,2603,2604,2605

or even better:

547,2601-2605

re: Mapping SQL Server Errors to .NET Exceptions (the fun way!)

Ali Kheyrollahi — Wed, 12 Sep 2007 16:53:42 GMT

This lack of flexibility was one of the reasons I did not like EHAB in the first place. I think exception type is not granular enough for applying policies and I started writing my own exception handling block but had to abandon it because of lack of time. One of the ideas I had was a regular expression pattern to test the exception message against it but that would not scale.

I am not sure if I am thinking just too wild, believe me I have not been on any marij.. but abstracting the exception into these elements can be possible:

1. Offending element

2. Offending operation

3. Offending condition

4. Check-rule element

5. Code

FileNotFoundException:

1. Offending element: The file name

2. Offending operation: access

3. Offending condition: NotFound

4. Check element: None

5. Code: None

Unique Key exception:

1. Offending element: new record

2. Offending operation: insert

3. Offending condition: duplicate

4. Check element: unique key ORDERITEM_TYPE

5. Code: None

COM Exception number 2147024809

1. Offending element: an argument

2. Offending operation: calling a method

3. Offending condition: invalid

4. Check element: None

5. Code: 2147024809

If each .NET exception could provide these elements, we could apply a lot more tules to them. It might need involvement of an NLP scientist but I think it is possible to abstract these.

EntLib Contrib September 2007 Release

Tom Hollander's blog — Tue, 02 Oct 2007 07:56:20 GMT

In keeping with the p&p team's tradition of naming a release after the month that's just finished,

5 reasons to download the EntLib Contrib September 2007 release

^(?:[^$]*)$ --Matches everything, captures nothing — Tue, 02 Oct 2007 12:43:00 GMT

This morning I woke up to Tom's announcement on the new EntLib Contrib release. No big surprises