Monday, March 21, 2005


Exception talk 1

Let's talk just about exceptions...

Except that it really isn't possible to talk JUST about exceptions, you need to also talk about try, catch and finally (and fault) blocks, and about finalization and Dispose patterns, about threads and aborts and system shutdown and appdomain unloading, system reliability and integrity, and all kinds of other stuff. It starts off simple and gets horribly complex, and I get reminded all over again that the software ankle is connected to the kneebone is connected to the hipbone is connected to...

This gets deep and hard fast, but that does not mean that it is impossible to talk about a few simple things, just that for every rule or best practice that can be devised there are exceptions :-) to that rule.

So I'll start off with the basics; just the facts Jack.

Fact 1: The exception mechanism used in .NET is very similar to that used in Win32 SEH, and rides on top of the C++ model as well. See Matt Pietrek's most excellent article on how Win32 SEH is implemented, available here
and on the .NET story, as told by the most excellent Chris Brumme, available here

Fact 2: Even though it is relatively easy to understand the actual mechanism used by the exception handling framework to deliver exceptions to code, it is very very difficult to come up with workable guidelines on how to design class libraries, components, modules, applications, and systems, to use them effectively. It's not that guidelines don't exist, it's that they are either misleading, do not cover all the cases, or provide simple homilies and bromides that are little more then admonishments to eat all your vegetables (I put the famous guide "there should be 10 times as many finally blocks as there are catches" in that category).

Fact 3: Even something that is relatively easy (the mechanism) is actually full of very complicated details. Most of these we don't need to worry about (such as the exception tables that contain the info needed to determine where in a method the catch block lies), but there are others that do affect user code, such as the translation process that occurs when an exception transitions from managed to unmanaged code (and back again). When information can get lost or translated, where one layer of code rubs against another, is a friction point, and it can cause problems; the world of interop is full of these points. I consider these to be moving parts, similar to a mechanical device, and all represent a point of failure.

So....I plan to start writing about this stuff. I do not work for Microsoft and I have no special knowledge of the CLR, and far less then others have. I also do not have a great deal of time to spend on this, and I doubt that anyone will actually read this stuff, but hey, it's 4AM and I don't feel like writing code right now. But I have read a lot on this subject, thought about it a fair bit, and have even conducted some training sessions for my company on this subject.
Comments: Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?