Exception management, the distributed way??

I want to brainstorm about a thing I thought about. On the current app im designing, Im using the microsoft appblock for exceptionmanagement. It allow me to easily publish exceptions.

The app is a client-server winforms app. It contains businesslogic at an appserver, as well as some webservices installed on the appserver that allow the client to perform some advanced features. When I thought about exception management, that came into mind was that I should create a database that stored all exceptions from all tiers and from all apps. For example, if an exception occured on a client, who want to visit that computer and open a logfile to read about it, or to have the customer mail teh logfile to our support? The best way would be for the exception to travel to the database where it is logged, and a mail is sent to our support, notifying them that an exception has occured. The webservices and the business logic and DAL should ALL use the same component for handling exceptions... no matter where it occured, it should be logged on the database. Then it is very easy for an admin or support to browse that database through some fancy .net GUI...

That means that ALL exceptions in an app, no matter WHERE it occured (in tier1, 2 or 3) or at a different physical location (client) all are stored at teh same place!!


what do you think about such an idea? Is it practically? How should I encapsulate the application block so I can allow it to be published as a webservice?

thank you for your comments!! Im looking forard to a rewarding discussion about this!!

kind regards
Henrik

I know what ur saying... I have gone down that road too.

What should you log?
I'm not so sure you would want EVERY exception to be returned and stored in the db. I think you could land up having a lot of useless information. Of course you would have the actual bugs in there, but there would be sooo much information (in general) that it would be difficult to isolate the bug information from the general exception information (obviously this depends on how and what you are logging).

I am not too familiar with the appblock, but the one I developed, I can set up handlers for the exception. So in my case, I would watch for a specific type of exception and only log those. In general, I would always be watching for fatal exceptions...you know, the kind where the application terminates all together.

Where should you log it?
I think you should be staying in line with the M$ standard as much as possible. This means, instead of using a separate db for your logging, try using the Windows Event Log. There are a few reasons for this:
[list=1][*]Consitency - Any technician familiar with Windows will know where and how to access error information.[*]Manageability - The Event Log comes with various features for manageability. [*]Enterprise Administration - An administrator can access the application logs from anywhere provided the computer is networked and he has the required priviledges to view them.[*]Availability of Tools - There are many tools available which can consolodate networked app logs[/list=1]

I would simply store the exception on the computer in which the exception is cought/handled and store relevant information in the event log.

As a developer, I would always want fatal exceptions mailed to me with as much information as possible (an entire memory dump of the app if I could!), but there are privacy issues involved in doing this. The safest is probably to log the exception as fatal and then notify the user (with a pretty screen) that a fatal exception has occured and they must contact their administrator or software support.

Conclusion
I have used a separate db before, but I just found it to be more of a headache than it was worth. My most successfull exception logging has made use of the event log. Also, I think it helps to log the error where it is relevant. I think that there are a number of tools out there that already do what you want to do, but they do it for all applications! Perhaps it is better to go with the standard???

Oh dear...

There are a number of factors that can affect any decision about exception logging on a three-tier application. To name just a few:

- How many clients? 2 is different than 10 which is different than 100.
- Are the client machines geographically dispersed?
- Does the client have rights to use the local event log?
- What is the level of support provided by the end user IT department? By you?
- Are you allowed to code for functionality that sends you exceptions automatically?
- Do you want to use server resources to log exceptions?
- If centrally posted, is there a case where you won't be able to log exceptions because of a server failure?

Obviously, the decision depends upon these and more and it may very well be the case that specific business cases call for different approaches.

To share my personal experience, some time ago I decided that the exception logging application block alone was insufficient mainly because exceptions are usually caused by a series of expected and unexpected events. At the end of the day, you don't want to be faced with a message of the type "Object reference not set to an instance of an object." without having a clue of the series of events that preceeded that error. Therefore, an application log felt more suitable (I think that MS also has a logging app block). When my company coded a .Net three-tier app (10-50 client users), we decided to keep the application log in a daily file locally stored on the client machine. At the early stages of the system's pilot run, this proved sufficient because we were on the spot and getting to the log file wasn't a problem. After several months that we're in production, we feel that it's time to code additional functionality to post some event types to a web service that will centrally store these events and we'll be able to get to them easily (or have someone mail them to us).

In our case, the use of the event log wouldn't have helped at all because of the large number of events we wanted to store and also there were some cases where a very large number of exceptions were logged. The event log by default doesn't like too many entries, of course you can change that but that's introducing administrative costs (if the customer doesn't centrally manage the event logs) and practices that some people may not agree with. However, like shunt has indicated, the event log provides numerous advantages...you'll just have to see if it's right for your specific need.

Like I said, much of your decision depends upon your specific application and I'm only sharing my personal experience that may not dictate a practice that's right for you. Also, you should keep in mind that your support contract policies may also need to be factored into this decision - for example, if you want to provide a standard 8x5 service with 3 hour response that's one thing, but if you want to provide a 24x7 service with 1 hour response you may want to make it a condition that critical parts of your application use "call home" technology (via e-mail or pager or fax or dial-in or whatever) if something is wrong (like an exception).

Cheers,
NTG

I think ntg puts a good point forward. It is really specific to you situation.

I think that M$ Logging App Block is the business. If you want dynamic logging, this is the guy to use. You will be able to snap in exception handlers, notifiers, loggers at run-time. You will also be able to develop your own notifiers to write/message whereever/whatever/whenever you want.

You could come up with your own Logging block, but why recreate the wheel. This design is very good and should cover anything you need to do.