Help to design exception policy

Topics: Exception Handling Application Block, Logging Application Block
Nov 27, 2008 at 3:02 PM
Edited Nov 27, 2008 at 3:09 PM
I need your help in implementing an exception policy. I have BLL which handles all exception from DAL. In most cases I'm fine by logging the original exception and sending email to support team and replacing it with BLLException with general error message but SqlException needs a specific handling as follows:
  • if SQL stored procedure returns a non-custom error I need
    • log the original exception as critical by using Logging Application Block which logs it and sends email
    • replace the SqlException with BLLException with general error message
  • if SQL stored procedure returns a custom error I need
    • replace the SqlException with BLLException using the error message from SqlException
    • no logging nor sending email required

I succeeded to create an appropriate BLLExcpetion by using a custom exception handler but I don't know how to re-route the exception to different Logging Application Block category or ignore the Logging handler at all.

Thanks in advance
Nov 28, 2008 at 3:58 AM
Edited Nov 28, 2008 at 7:08 AM
Hi,

Just want to ask, How would you distinguish the custom error from the non-custom? do you do it on your Custom exception handler? You can try the logging programmatically so you can control which category to use for logging.


Valiant Dudan
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com
Nov 28, 2008 at 1:02 PM
Yes, in the custom exception handler. How can I reproduce programmatically the same logging behaviour as it's done in a Logging exception handler? Ideally, based on the exception type I should be able to trigger a Logging exception handler or skip it.
It looks like a simple workflow which is probably the suggestion to the next EHAB release.
Dec 2, 2008 at 5:48 AM
Hi,

You can find some examples of logging programmatically in the Documentation.

Here is a sample code:

if(IsNonCustom)
{
//this code logs the entry together with your configured sources in your .config file
LogEntry entry = new LogEntry();
entry.Categories.Add("SendEmail");
entry.Categories.Add("LogToEventLog");
entry.Severity = System.Diagnostics.
TraceEventType.Critical;
Logger.Write(entry);

//process the replacing of the exception

}
else
{
    //Just process the replacing of the exception
}


Valiant Dudan
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com
Dec 2, 2008 at 2:58 PM
Thanks for reply. Finally I did as you suggested but added exception formatting by the deafult text formatter:

if(IsNonCustom)
{
//this code logs the entry together with your configured sources in your .config file
LogEntry entry = new LogEntry();
entry.Categories.Add("SendEmail");
entry.Categories.Add("LogToEventLog");
entry.Severity = System.Diagnostics.
TraceEventType.Critical;

 

System.IO.StringWriter writer = new System.IO.StringWriter();
TextExceptionFormatter formatter = new TextExceptionFormatter(writer, exception);
formatter.Format();
entry.Message =
writer.ToString();

Logger.Write(entry);

//process the replacing of the exception

}
else
{
    //Just process the replacing of the exception
}


The only thing I don't like in this solution is that I must add a logging handler into the excpetion handler which means breaking the nice EntLib concept with the flexible exception policy configuration. Besides, I hate hard coding category names - it's not flexible and will cause a potential run-time issues.
I would suggest a simple improvement in this logic by adding a hanlder property "StopProcessingOtherHandlers" which would introduce a simple workflow. Having that, in my case I would have the follwoing handlers:
- Custom exception handler
- Logging handler
In the custom handler I would set StopProcessingOtherHandlers = true for non-critical error which skips the next Loggin handler.

//process the replacing of the exception} else{    //Just process the replacing of the exception}The only thing I don't like in this solution is that I must add a logging handler into the excpetion handler which means breaking the nice EntLib concept with the flexible exception policy configuration. Besides, I hate hard coding category names - it's not flexible and will cause a potential run-time issues.I would suggest a simple improvement in this logic by adding a hanlder property "StopProcessingOtherHandlers" which would introduce a simple workflow. Having that, in my case I would have the follwoing handlers:- Custom exception handler- Logging handlerIn the custom handler I would set StopProcessingOtherHandlers = true for non-critical error which skips the next Loggin handler.

Thanks,

Michael