One of the primary success factors for implementing a robust framework is providing enough information at runtime so that the system can be effectively monitored. Despite how good a programmer you think you are, there will always be bugs. Hopefully, by the time your application goes to production, most of these can be discovered. However, no matter how diligent you may be, problems still arise. Eventually, you will be faced with solving the issue as quickly and as painlessly as possible. The better your framework is built to handle both preproduction and postproduction problems, the faster they will be solved.

Information is key to solving any problem. The more accurate, abundant, and accessible the errata, the better. This is especially true in postproduction, when you may not have the liberty of being seated at the desktop of your users trying to solve their issues. I hope the topics in this chapter will provide you with some “best practices” that you can employ in any application, typically at the middle tier. I provide a melee of ideas, dos, and don'ts here to give you a few tips on which can be incorporated at any level. Unlike design patterns, these are not fixed to any one design but are more specific to the .NET framework. For those repeatable implementation steps, I've included a few implementation patterns that will add some benefit to any new or existing middle tier.

Like the remaining the chapters in this book, this chapter serves as a cookbook of ideas and does not have to be read in any particular order. The following topics will be covered in this chapter:

• Exception Handling
• Exception Logging
• Exception Chaining
• Building a Base Exception Class
• Tracing and Trace Listening
• Error and Call Stacks
• When, Where, and How to Log
• SOAP Exceptions and SOAP Faults
• Interop Exception Handling

The following implementation patterns will be described in detail:

• Remote Tracer
• Custom SOAP Exception Handler
• System Exception Wrapper
• SOAP Fault Builder

Those already familiar with Java exception handling should feel quite comfortable with the .NET implementation. In fact, if you are reading this book, you should already be throwing and catching exceptions in your code. However, I would like to go over some “advanced-basics” in the area of exception handling before we move on to creating a “base exception” class (sprinkled with a few implementation patterns). Error, or exception handling is one of those things that everyone does but unfortunately, few do it very well. With robust handling, logging, and display, your applications will better stand the test of time and should save you hours in product support. From here forward, I use the word exception in place of error, and vice versa; neither is meant to be distinctive of the other. I assume throughout this chapter that you have already had some experience working with structured exception handling (SEH) because this will not be a tutorial on its basics.

Figure 2.1 illustrates a typical exception-handling scenario. This should provide you generally with the proper flow of throwing and catching exceptions. You'll notice that once an exception is deemed unrecoverable, information is then added to provide the system with as much information as possible for determining the problem. This is where a base exception class becomes useful. Typically, the more you can centralize value-added features to this class, the easier it will be to integrate and leverage from within your framework. This is especially true of large development teams. How many times have there been framework features that were useful but unused? By centralizing important functionality such as logging in your base class and by standardizing how the exceptions should be thrown, you help guarantee its proper use. This also takes any guesswork out of proper exception handling for those developers using your framework. In an upcoming section, I will provide some of the steps for creating such a base class.

Figure 2.1. Exception flow: How most exceptions should be handled.