Article Options
Premium Sponsor
Premium Sponsor

 »  Home  »  .NET Framework  »  Exception Handling in Enterprise Applications
 »  Home  »  .NET Newbie  »  Exception Handling in Enterprise Applications
Exception Handling in Enterprise Applications
by Scott Rutherford | Published  02/28/2005 | .NET Framework .NET Newbie | Rating:
Scott Rutherford
Scott Rutherford is a consultant and .NET developer who has developed Enterprise business applications in many fields including Restaurant, Market Research, Automotive, and Analytical Chemistry. He is an Microsoft Certified Professional with the .NET Platform. 

View all articles by Scott Rutherford...
This article assumes a general understanding of Structured Exception Handling in .NET (VB or C#).
This article is supplemental to the MSDN article: Best Practices for Handling Exceptions (read this!!!).

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

Sponsored Links