Exception handling is often understood to mean "exception stopping". That is, make my program continue to run without stopping and without requiring human interaction. However, exceptions can be lifelines that help you maintain the health of a dynamic Enterprise application. Often you will want to track and respond to an application that is not self-contained in a single process, or on a single machine.

In this article, I suggest eight "Best Practices" to implement in Enterprise Applications, with code examples to show how it's done. If you consider the suggestions below early in the development process, and follow these practices in all applications, you will reap the benefits on the Enterprise scale.

1. Always include the Source Exception, using InnerException
2. Uniquely Identify error locations in your code
3. Identify the Importance of the error
4. Act on the Urgency of the error
5. Handle errors Centrally, but use available Context
6. Report errors to Windows Event Logs
7. Ensure all apps can Write to Windows Event Logs
8. Use Enterprise Tools to identify program errors

The basic rule is to ensure your exceptions are raised with codes that are programmatically, or at least systematically, readable. And always use the Windows Event Logs to report errors.  This will allow you to use Enterprise tools to monitor and respond to logged errors. The main benefit of following these practices is that all program errors are centrally reported and uniquely identified. This gives Enterprise administrators the power to identify and respond to all program errors.

Here are some examples of real life applications in which I implement these rules:
• An ASP.NET application that opens a window to the Enterprise for outside clients
• Various desktop apps
• Windows Service that picks up data files from legacy apps at remote sites
• Data broker component that provides database access in various ASP.NET applications
• Windows Service that monitors processes and log files running on remote machines