In the Microsoft Windows API, you can use SetUnhandledExceptionFilter, to set a handler for unhandled exceptions. The big catch, mentioned on that page, is:
If an exception occurs in a process that is not being debugged, and the exception makes it to the unhandled exception filter, that filter will call the exception filter function specified by the lpTopLevelExceptionFilter parameter.
(emphasis added)
Which basically means, if the process is getting debugged, the debugger gets the exception, and my filter is skipped!
I can test & debug my ExceptionFilter the old-fashioned way, with printfs and trial-n-error.
But am I missing something? Is there a good way to interactively debug an ExceptionFilter if it is disabled when in a debugger?
Checkout the Resolution section of KB173652 which talks about placing all the code in main/WinMain in a _try/_except block like the following.
void main (int argc, char **argv)
{
__try
{
// all of code normally inside of main or WinMain here...
}
__except (MyUnFilter (GetExceptionInformation()))
{
OutputDebugString ("executed filter function\n");
}
}
Another article, Debugging custom filters for unhandled exceptions, describes a couple more techniques in addition to the one above. I personally use the one where you display a message box inside your exception filter and then attach the debugger. I use IsDebuggerPresent to determine whether to display the message box or not.