I work on a fairly large project, and end up having scope over a great number of areas. Unfortunately this normally means I get to think about the breadth of things and not the depth of things. While folks like Daniel get to do the cool work of building our 3D code, I get to think about how all of this hangs together.

One of the "big" things I've gotten tasked with lately is working on our reliability plans. Lets take the simple sample (assume this code is inside of Avalon for the moment):

private InternalMeasure(Size availableSize)
{
    if (_dirty)
    {
        _dirty = false;
        MeasureCore(availableSize);
    }
}
protected virtual MeasureCore(Size availableSize) { ... }

Of course, the failure here is obvious (uhm, yeah). If a 3rd party deriving from this class has bad code inside of their MeasureCore method and throw an exception, the _dirty bit will incorrectly set to false. So, the next time layout tries to run (assuming the application decided to swallow the exception, more on that later), we are in an bad state.

This is a vast oversimplification of the problem, but for the next couple days I'd like to talk about some of the issues and dillemas that we are hitting while trying to write really robust managed code. There are debates about how to deal with out of memory conditions (remember, if _dirty was typed as an object than the CLR would have had to allocate memory to assign false to it when it boxed the bool <G>), stack overflow, thread abort, user exceptions, global exception handlers, and more.

I'm not the best expert at this, I've been learning a lot about the various options over the past several weeks, so it should be interesting to hear what everyone thinks...