Disclaimer

I am not MS certified developer and my opinion and code may have some bugs.
Use it carefully at your own risk.

Introduction

After familiarization with .NET Framework and System.Exception Object everyone can exclaim
"Wow, it's really cool to be able to trace a call stack via a single call of Exception.StackTrace".
But I write most of my working projects in VC++ 6.0. and I want to have a similar feature there too.
Fortunately I can easily implement an "exception with stack trace" in C++.
I recommend strongly to read the book "Debugging application" by John Robbins
to get a better understanding about the subject.
You can find here some ideas\code from John Robbins's book throughout my code.
Also you can read the source code of my demo program and at last read this article too.

Main

Every programmer sometimes errs and tries to work with a wrong pointer.
And it's real headache to detect the line of code with the bug.
Look at this example of code with just such an annoying "access violation" error

For obtaining a stack trace we need a CONTEXT structure. And we can get it
via call GetExceptionInformation() in the filter expression of an SEH exception handler.
Ok. But we can't get such info in C++ catch(...) block. So, then we have to call the se_translator class for help.

The se_translator class maps win32 structured exceptions into C++ typed exceptions via _set_se_translator API.
The CP site already has article SEH and C++ Exceptions - catch all in one by Martin Ziacek about using _set_se_translator and I don't want to repeat it.
Instead I rewrite foo() function in C++ style.

At first, I've installed a new translator function and now I can handle structured exception like C++ exception.
I've wrapped every structured exception into C++ class. The base class is se_translator::exception.
And for example several derived classes : se_translator::no_memory, se_translator::access_violation, se_translator::int_divide_by_zero, etc.

Yes, now we've grasped the way to obtaining stack for Win32 structured exception.
But interesting, is there any way for obtaining similar info for native C++ exception like std::exception and so on ?
Hm, I can't achieve it, but can propose a workaround.
We can define the new exception class derived from std::exception which will hold the class stack's info.
Let's name it exception2 class.

At last the final class which I want to present it's exception_trap class.
What if exception will be raised out from any exception frame ?
Most likely the users will phone and terrorize your QA and you will tear hair at a loss.
But if you could have a look at the crash's call stack definitely your life would become more easy.
The exception_trap class wrapps
SetUnhandledExceptionFilter API and can print out the crash's cause, call stack and another useful info.
For this you must just define somewhere global variable.

exception_trap<> trap;

Enjoy

Some traps

As any programmer knows, any good idea always has a some traps. In that case it's in synchronous exception model (/EHs compiler option) and _set_se_translator API.
Sometimes due to optimization reasons the compiler can avoid to generate code for try\catch block. See MSDN article for more info.
Hence if access violation or another exceptions will be occured nobody can catch it and tricks with SE translator will useless here.

and don't forget to place the .pdb file in the same folder with your .exe or .dll file (see MSDN topic SymInitialize for more info)
And again I point to the book "Debugging application" by John Robbins for more info about
program database problem.

Thanks

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

Share

About the Author

I am freelance programmer. About 3 years of experience in C++ and I would rather use ATL, STL, WTL but not MFC . Main backgrounds are Win32 API, COM and Networking. Now I am interested about AI (Neural Network, Fuzzy Logic and GA). Currently based in Vladivostok, Russia.

Comments and Discussions

One thing I couldn't get: why not use 'GetExceptionInformation' for retrieving thread CONTEXT structure when an exception was thrown, instead of creating second thread then resuming the first one, then using GetThreadContext from the second for the first one?