Looks like a routine C++ question. Unless I missed something, the RAII idiom applies. Replace your naked pointers by a class (an instance of a template such as an std::auto_ptr would suffice; or the boost shared_ptr is a good alternative should the semantics of how you're using the object require it). You create an instance of your object holding the resource and you are guaranteed it will be cleaned up regardless of what exit path you follow. If an exception occurs, the instance of the class will be cleaned up as part of how the stack is unwound. If you exit normally, it will be cleaned up once it goes out of scope. No need for syntactic sugar like __try/__finally. I don't know about what others prefer to do, or common practice if there is such a thing, but to me what passes for common sense is that avoiding vendor extensions whenever possible minimizes the pain experienced when the code must pass through another suite of development tools. And I like to pass my code through two different tool chains, just to catch potential issues that one is better at catching than the other. In other words, if it ain't in the standard, I don't use it unless there is really no other choice. In the 15 years I have been using C++, I have never found it necessary to use anything not in the standard (since it first apeared), and as a result I generally have no problem compiling it with any of the tools I regularly use (GCC and MSVC). What you say suggests you ought to take an hour or two to study RAII (resource acquisition is initialization), and see how far that allows you to clean up obviously problematic code. HTH Ted
