- Table of Contents
- .NET Book Recommendations
- What Is .NET?
- The Microsoft .NET Framework
- The Common Language Runtime (CLR), the Common Type System (CTS), and the Common Language Specification (CLS)
- .NET Framework Class Library
- Visual Studio .NET
- .NET Enterprise Servers and .NET My Services
- .NET Compliant Languages
- C#
- Visual Basic .NET (VB .NET)
- ASP.NET
- XML Web Services
- ADO.NET
- XML.NET
- Windows Forms
- Why .NET?
- Displaying Errors with the Error Provider
- COM Interoperability
- Comparing Java and .NET
- Calling Unmanaged Code
- .NET Application Security
- Code Access Security
- .NET Standards Support
- Numeric Types in the .NET Framework
- Working with Strings
- Formatting Strings
- Trimming Character Strings
- Comparing Strings in .NET 2.0
- Arrays and Collections
- Arrays as Class Members
- Sorting a Multi-Dimensional Array
- Sorting a Multi-Dimensional Array with LINQ
- File I/O (System.IO)
- Working with File Names
- Using the File System
- Working with Files and Directories
- Monitoring the File System
- Working with Streams
- Working with Text Encodings
- Working with Date and Time
- Extending the DateTime Class
- Fun with Dates
- Exceptions
- Delegates
- Events
- Asynchronous Programming
- Asynchronous File I/O
- Timers
- Random Numbers
- Cryptographically Secure Random Numbers
- Serialization
- MultiThreading (System.Threading)
- Multi-Threading Overview
- The Managed Thread Pool
- Managed Threading
- Thread Synchronization
- Synchronizing Data Access
- Trace Debugging
- Tracing in .NET 2.0
- ASP.NET Trace
- Validating User Input in ASP.NET Web Pages
- Event Logging
- Monitoring Application Performance
- Accessing the Registry
- Accessing Environment Information
- Environment Variables in .NET 2.0
- Managing Windows Forms Applications
- Working with Email
- Working with Graphics
- Animating a Background
- Working with Images
- Drawing Cycloid Curves
- Simulating the Spirograph
- Building International Web Applications
- .NET Compact Framework
- Mobile Web Development with ASP.NET
- Speech Technologies
- Microsoft MapPoint Web Service
- Working with Typed DataSets
- Using Relationships in DataSets
- DataColumn Expressions
- Playing Simple Sounds
- Playing Sounds with .NET 2.0
- Returning an Image in a Web Page
- RSS
- Best Practices Project Structure
- Best Practices Application Blocks
- The Data Access Application Block
- The Exception Management Application Block
- Best Practices — Performance
- Best Practices — Performance and Scalability
- Best Practices - Testing
- Reading the Tea Leaves, 2005
- Predictions: A Look Back at 2005, and a Look Ahead to 2006
- .NET Downloads
- Application Deployment Overview
- Application Deployment — Versioning
- Application Deployment — Version Policy
- Application Deployment — Packaging and Distribution
- .NET Remoting Overview
- A Remoting Demonstration
- Remoting Configuration
- Remoting: Lifetimes and Leases
- Remoting: Other Issues
- Attributes
- Writing Custom Attributes
- Accessing Attributes in Code
- Reflection
- Class Design: Inheritance, Interface, or Composition?
- The TriTryst Game
- Console Applications in .NET 2.0
- New File I/O Methods in .NET 2.0
- Building Projects with MSBuild
- Unmanaged Callbacks in .NET 2.0
- Timer Troubles
- Non-Rectangular Windows Forms
- Windows Forms Transparency
- 10 Things I Hate About Visual Basic
- 10 Things I Hate About C#
- Background Processing with Idle Time
- Scaling Windows Forms
- Reading and Writing Binary Data
- New Memory Management Functions in .NET 2.0
- Compatibility Between .NET 1.1 and .NET 2.0
- Managed Debugging Assistants in .NET 2.0
- XDir: A Program for Viewing Directory Sizes
- The Microsoft.VisualBasic Namespace
- Operator Overloading
- Working with GPS Data
- Hidden Visual Studio Tools
- .NET 3.0
- The .NET 2.0 Stopwatch Class
- Nullable Types
- Drawing Rotated Text
- Unsafe Code
- Other .NET Languages
- Compiler Directives
- Safe Handles
- Predictions, 2007 Edition
- New Features in C# 3.0
- Generics
- Network Client Programming
- On the Misuse of Exceptions
- Maximum Object Size in .NET
- More on Maximum Object Sizes
- Keyed Collection Memory Limitations
- Matching String Endings
- Allocating Small Data Structures
- Grumbling About Limitations
- Some Thoughts on the Nature of What We Do
- Working with Predicates in Collections
- Working with DataReaders
- Outputting XML with XmlWriter
- Writing XML Data
- Working with Compression
- Another Look at Compressed Streams
- Compressing a Very Large File
- Canonical URIs
- Constructing URIs
- Using OneWayAttribute for Remote Calls
- Selecting a Garbage Collector
- Linked List
- Linked List Application - The MRU List
- Auto-implemented Properties in C#
- The HashSet Collection
- Looking Ahead: 2018
- An Experiment in Optimization
- A Larger Integer
- Extension Methods
- Language Integrated Query (LINQ)
- Variable Length Parameter Lists
- The ReaderWriterLockSlim Synchronization Primitive
- Sorting a Text File
- Sorting a Large Text File
- Using ListView with Large Data Sets
- LINQ One-Liners
- Regular Expression Optimization
- Random File I/O
- Computing the Size of a Structure
- More on Computing Structure Sizes
- UnmanagedMemoryStream
- Dynamically Loading Code
- Building a String Table
- Delegates Versus Function Pointers
- Visual Studio Editor Features
- A Simple Profile Timer
- New Features in C# 4.0
- IEnumerator or IList?
- New Features in .NET 4.0
- Set Operations with IEnumerable and HashSet
- Using File Locks
- Extending Object Functionality
- Clearing a HashSet
- When Hash Codes Matter
- Parsing Command Line Options
- Creating a Single-Instance Program
- Asynchronous Windows Forms Events
- The BackgroundWorker Component
- Fixing a Dumb Mistake
- Thinking About Multi-Threaded Programs
- JavaScript Object Notation
- Useful .NET-related Sites
- Markov Models
- Building an Order 0 Markov Model
- Higher Order Markov Models
- Webmaster's Guide to robots.txt
- An Overview of the Parallel Extensions to .NET
- Parallel Extensions Synchronization Objects
- Thread Safe Collections
- A Bug and a Conundrum
- Another Bug and an Answer
- Task Parallel Library
- Good and Bad Ideas in C#
- Parallel LINQ
- Copying Large Files
- Replacing File.Copy
- Learning from Our Mistakes
- Symbolic Links
- There Is No Easy Fix
- Tracking Hurricanes
- Examining Hurricane Data
- Searching for Multiple Strings
- Simple JSON Processing
- Aho-Corasick String Searching
- Writing a Web Crawler
- Web Crawler Politeness
- Source Control Management
- Subversion
- Communicating with Datagrams
- Fun with Actions and Funcs New
- The Future of Media
- The Importance of Metadata
- Of Comparison and IComparer
- IComparer, Comparer, IComparable, Oh My!
- Comparing Generic Types New
- A Simple HTTP Server New
- Informit Reference Library
The Exception Management Application Block
Last updated Nov 18, 2004.
The use of exceptions in .NET programming allows you to confine error handling to one or a small number of program areas. This is in contrast to environments that depend on HRESULT or other return codes that must be checked for each operating system call. With exceptions, rather than checking each function's return value, you write your code with the assumption that everything went right. You then wrap that code with an exception handler that will process any error conditions that arise. In simple programs, you often can get away with a single exception handler. More complex programs require multiple exception blocks. See the Exceptions topic for an introduction to exception handling.
Although naked .NET exceptions are useful for simplifying error handling, there is no provision for publishing the exceptions that occur. If you want all exceptions to be written to the event log or logged to a file, you have to write a considerable amount of custom code that is somewhat complex and difficult to get right.
Enter the Exception Management Application Block for .NET. This application block provides a simple, extensible, and configurable framework for handling and publishing exceptions. With a single line of application code in your exception handler, you can publish exception information to the system event log in a standard format. With slightly more work, you can create your own exception publisher that does whatever you want with the exception. For example, you could write the information to a log file or send an email to those responsible for the application. The Exception Management Application Block helps you:
Manage exceptions consistently and efficiently.
Isolate exception management code from business logic.
Handle and log exceptions with a minimum of custom code.
Although it's possible to create your own exception publishing interface without the Exception Management Application Block, doing so effectively and efficiently is somewhat difficult. The Exception Management Application Block is free, tested code that is used with great success in many .NET applications. Although the code is supported "as-is", many programmers use it and provide informal support on Microsoft newsgroups. Official support is available from Microsoft for a fee.
A Sample Catch Statement
A typical try/catch block that uses the Exception Management Application Block would look like this:
[C#]
try
{
// application code here
}
catch (Exception ex)
{
ExceptionManager.Publish(ex)
}
[Visual Basic]
Try ' application code here Catch ex as Exception ExceptionManager.Publish(ex) End Try
That assumes, of course, that you've included a reference to the Exception Management Application Block in your code, and that you've configured it correctly.
Installation
You can download the Exception Management Application Block from the Microsoft Download Center link above. When you run the install package, it will install the application block code, documentation, and examples on your system. The following items are installed:
Exception Management Application Block source code in C# and Visual Basic
Quickstart Samples in C# and Visual Basic
Documentation
The documentation is quite extensive. It includes sections on developing applications, deployment and configuration, and internal design of the Exception Management Application Block. The reference section documents all of the classes and interfaces that are implemented by the package.
After you've run the install package, you have three options for including the code in your project. You can:
Copy the Exception Management Application Block project files from the install directory to your own application's directory, and include it as a project in your solution.
Compile the project and copy the resulting assemblies to your application's directory and make file references to them.
Compile the project and install the assemblies in the global assembly cache. Again, you would create a file reference in your project.
The supplied documentation covers each of these options quite well.
There is one final step you need to take before your programs can use the ExceptionManager class. You have to invoke the ExceptionManagerInstaller class to create the event sources that the default exception publisher uses. This is done at install time rather than at run time so that the application program doesn't need the elevated privileges required for creating event sources. If you use a .NET Setup and Deployment project to create a Windows Installer file for your application, the ExceptionManagerInstaller class will be set up automatically. If you use some other method of installation (XCOPY deployment, for example), then you need to run the Installutil.exe system utility to install against the Exception Management assembly.
Using the Exception Management Application Block
Once you've installed the application block, you can begin using it in your programs. You can publish any exception with the ExceptionPublisher class. For example, here's a simple program that throws an exception and publishes it to the event log using the default publisher:
[C#]
using System;
using Microsoft.ApplicationBlocks.ExceptionManagement;
namespace exb_cs
{
class Class1
{
[STAThread]
static void Main(string[] args)
{
try
{
GoDoSomething();
}
catch (Exception ex)
{
ExceptionManager.Publish(ex);
}
}
static void GoDoSomething()
{
throw new ApplicationException("Big bad error here");
}
}
}
[Visual Basic]
Imports Microsoft.ApplicationBlocks.ExceptionManagement
Module Module1
Sub Main()
Try
GoDoSomething()
Catch ex As Exception
ExceptionManager.Publish(ex)
End Try
End Sub
Sub GoDoSomething()
Throw New ApplicationException("Big bad error here.")
End Sub
End Module
This program doesn't do anything but throw an exception. If you run it, it will just return to the command line. However, it publishes the exception in the event log. If you start the event viewer (from the Administrative Tools menu) and look in the Application Log, you will see the exception, as shown in the figure below.
If you double-click on the event, the Event Properties window appears, giving you more detail about the exception. For a naked .NET exception, the information is the same as what you'd see if you called ex.ToString() on the exception object.
Although you can use the ExceptionManager to publish standard .NET Exception types like ApplicationException as shown above, the Exception Management Applicaton Block documentation recommends that you instead derive your application's exceptions from BaseApplicationException. Doing so provides some additional contextual information in the exception object itself, which can be quite useful when you're reviewing an exception log.
Configuration
The default configuration uses the default publisher to publish exceptions to the Application event log. This method is used when there are no exception management settings in the application's configuration file, or if there is no configuration file at all. However, there are several settings that you can use to change how exceptions are published.
The code below shows how to include exception management in your application configuration file.
<configuration>
<configSections>
<section name="exceptionManagement"
type="Microsoft.ApplicationBlocks.ExceptionManagement.ExceptionManagerSectionHandler,
Microsoft.ApplicationBlocks.ExceptionManagement" />
</configSections>
<exceptionManagement mode="on/off">
<publisher mode="on/off" assembly="AssemblyName" type="TypeName"
exclude="(+)Type;(+)Type" include="(+)Type;(+)Type"
exceptionFormat="xml"
customattr = "value" />
</exceptionManagement>
</configuration>
The first part, configSections defines the section name and the assembly to which it pertains. The exceptionManagement section contains the exception management configuration settings. Note that the settings in the sample code above describe the syntax. This is not an actual configuration file. Configuration settings allow you to turn the publisher on or off, specify what types of exceptions are included or excluded from the publisher, and the format to be used for the log data. If you set exceptionFormat to "xml", then the log information is streamed in XML format.
If you're using the default publisher to publish exceptions to the Application log, you probably won't need to configure it. If you create a custom publisher, though, then you'll need to enable it through the configuration file. You can create and enable multiple publishers and configure them to publish all exceptions, or have some exceptions go to one publisher and other exceptions go to a different publisher.

Figure
38

Account Sign In
View your cart