Written by:
2010-08-10T10:41:05 

For a few years now, I've incorporated the EHB into my projects. I have yet to come across any blogs that suggest a technique for choosing the actual policies that one might apply to EHB.

All of the examples I've seen have one of three unhelpful variations:

1. "General Policy" or "My Custom Exception Policy"
2. "Policy1", "Policy2", etc.
3. "Wrapped Exception Handler Policy" or "Replace Policy"

The first variation is not helpful because it is just a giant bucket. Everything fits inside. Policies are only useful if there are more than one, and there is some way to distinguish what should go into one versus another.

The second variation is not helpful because it just makes smaller buckets without value.

The third uses a name which presupposes the way in which the policy will always handle the exception. If I'm the developer, and I know I need to use the "Replace Policy", why don't I just skip the handler and replace the exception on my own? Then all I need to do is possibly log the exception, or, just have all of the exceptions handled by the "General Policy" so that the logging happens automatically, but still do the replacement on my own.

Some of the policies that I have used in the past were based on the tier of the n-tier application, or one the category of cross-cutting infrastructure modules that were applied. For example, I've used:

• Administration (the module that uses this policy provides general support for logging, configuration, performance counters, etc.)
• Security (the module that uses this policy provides access control support)
• Presentation (the tier which generates HTML for ASP.NET Web Applications)
• Data (the data access tier)

And so on. Although this technique makes it pretty simple to decide which policy to use, I'm not sure it helps very much with manageability.

The point of the EHB (in fact, all of the application blocks) is to allow system engineers to change the behavior of the application after it has been deployed using configuration files. What makes sense to system engineers when they think, "This application is raising exception X and I want it to either raise exception Y, or don't raise anything, or …." How would they know which policy to change?

I have no answer to this yet.

Trackback Print

Tags:

Categories:

Location: Blogs Code Charm

Your name:
Your email:
	(Optional) Email used only to show Gravatar.
Your website:
Title:
Comment:
Security Code Enter the code shown above in the box below
Add Comment   Cancel