EnterpriseLibrary ExceptionHandling is not writing to my log file

Question

Hi, I have enterprise logging & exception logging enabled in my web app. The web.config is set-up so everything should work. It has worked before on other servers because the trace.log file which is in the root of the application has trace information in it. I cleared my trace.log on my local machine to test that it is working when I get exceptions. I've created a test page which throws an exception. I then call ExceptionPolicy.HandleException(ex, "Exception Policy") and rethrow if required. My trace.log is staying empty so I can't work out why it isn't working. I'm fairly new to this, but I know this must have worked before. What I'm not sure is, will the exception be written to the log file anyway, or only as a result of the HandleException() call?

I'm struggling to debug why this isn't working.

Answer 1

I worked this out in the end and am documenting to help me & others. It was down to my lack of knowledge of how this works and also the strange code that our contractors have written.

Basically our stack consists of

DA layer BO layer App layer

The BO layer accesses the DA. If something goes wrong then it is handled within a Try/Catch. Inside the catch it calls ExceptionPolicy.HandleException() and returns the rethrow boolean value. However it doesn't check this value to carry out another throw, which means the error is not proprogated to the ASP.NET error runtime.

Strangely, they set a IsExceptionGenerated flag on the BO object which is then checked on the App layer. The App layer then redirects to '~\error.aspx'.

I've changed this so the policy is checked and exception re-thrown. But there is nowhere where the exeception was logged. I don't want loads of logging scattered throughout the application just before the redirect to error.aspx. Therefore I have added global.asax error handler to log the error. I may also rip out all the redirects and let the web.config specify the direct to the error page using CustomErrors section.

It now seems to work!

I would like to know if response.redirects("error.aspx") is bad practice throughout my application though. I would like to know what they were thinking when they wrote this. I can understand that sometimes you may want to error out, and sometimes carry on gracefully but still trace it, but surely this can be handled by using different Exception Policies.

Any ideas anyone?