Where's the catch(...)

| 0 Comments

As of the next release of The Server Framework use of catch(...) handlers at thread boundaries, in 'no throw' functions and in destructors will be configurable.

At present, in v6.0 and earlier of The Server Framework, we use catch(...) judiciously at thread boundaries in functions that are either marked as 'no throw' (with throw()) or which are 'implicitly no throw' and in some destructors. Generally these handlers let the user of the framework know about the unexpected exception via a callback. Generally there's not a lot you can do about it except log it and hope to find the cause later. I've always felt that this approach was the lesser of two evils. It has definitely led to more robust servers for some clients where the client code has a hard to track down bug that only appears rarely and the server can continue to serve clients with the occasional 'glitch'. The alternative is that the server shuts down which may or may not be better. The catch(...) approach gives you the option, generally.

Some clients have asked that we don't do this. They prefer to let unhandled exceptions bring the server down and then have a post mortem debugger deal with it. As of the next release of the framework you can configure when and where catch(...) are used with several configuration options in your Config.h file.

Actually implementing this change was reasonably straight forward, essentially it means converting code like this:

try
{
   doThing();
}
catch(const CException &e)
{
   // tell someone...
}
catch(...)
{
   // tell someone...
}

To code like this:

try
{
   doThing();
}
catch(const CException &e)
{
   // tell someone...
}
CONDITIONAL_MACRO_THING
{
   // tell someone...
}

Where the expansion of the CONDITIONAL_MACRO_THING depends on the settings you configured in Config.h. If you go for the default settings then CONDITIONAL_MACRO_THING expands to catch(...) and there is no change in functionality. If you decide to turn off catch(...) handlers then the CONDITIONAL_MACRO_THING needs to expand to a catch that wont catch anything and that is trying to catch something that a) can't be throw and b) wont already be being caught. To achieve this I create a simple new exception class which is never thrown and so CONDITIONAL_MACRO_THING expands to catch(const thingThatIsNeverThrown &) if you turn off catch(...). Seems to work well and gives everyone the option to deal with these issues in a way that's appropriate for their project.

These changes will be included in the version 6.1 of The Server Framework which currently has no scheduled release date.

Leave a comment