global exception handlers in MFC

[Schol-R-LEA]

Is it possible to set up a global exception frame in a VC++ program built using the Application Wizard? In a conventional C++ program, I would normally put a [tt]try[/tt]/[tt]catch[/tt] frame at the top level of the [tt]main()[/tt] function, like so:

Code: Select all

int main(int argc, char* argv[])
{
  try 
    {
      // program code goes here
    }
  catch ( ... )
    {
      // default exception handler goes here
    }
}

In a program written using only the WIN32 API calls, I expect one would do the same in [tt]WinMain()[/tt]. However, AFAICT, there is no equivalent top level method for the [tt]CxxxApp[/tt] class generated by the App Wizard; neither the class constructor, nor [tt]InitApplication()[/tt], nor [tt]InitInstance()[/tt] seem to be where it should go. Is there anywhere else I could try - the program's [tt]CMainFrame[/tt] class, for example? Is it even possible to set up a global exception handler in MFC, without resorting to [tt]set_unexpected()[/tt] and [tt]set_terminate()[/tt]? The books I've seen on VC++ and MFC all seem to give little if any coverage to exception handling; usually all they do is reiterate the basic C++ mechanism, without addressing how it would apply to an MFC application.

Also, is there any advantage to using the [tt]TRY[/tt]/[tt]CATCH[/tt] macros instead of the built-in [tt]try[/tt]/[tt]catch[/tt] expressions?

Finally, is there any reasonable way to compile an AppWiz-generated program using another compiler (specifically, MingW gcc 3.2 run from Dev-C++) without modifying the code to such an extent that it would no longer work with VC++? This is not a critical task, but I prefer to check programs with another development environment whenever possible, as a way of highlighting problems which the original compiler might have missed.

Please bear with me if I seem to have any obvious misconceptions about MFC and AFX; I have, up until now, largely avoided them, as they seemed more complicated than they were worth (even compared to the bare Win32 API). When I first read about it years ago, my impression was that it is an excellent example of how not to design a GUI object API, and I have yet to see anything that would convince me otherwise (though in all fairness, I have yet to see what I would consider to be a good GUI API for C++ under any system).

Since I will doubtless have to do more C++ MFC programming in the future, I would like to finally learn it, but so far it has been quite aggravating (I've been told that after working with it for a coule of months it will make perfect sense, but I'm not sure I believe it). Any elucidation or advice (including web pointers and book recommendations) would be helpful.

[ark]

the best reference I personally have found for MFC is Programming Windows with MFC, Second Edition by Jeff Prosise. that book starts you out writing MFC apps from scratch, without using the AppWizard and all the extra bells and whistles that it adds, which taken in the context of application development may be nice but in the context of learning are unneeded baggage.

I'm not 100% sure where a global exception handler would go in MFC, if such a thing is even possible. the problem, of course, is that all the message-dispatching code is hidden away inside the library and you never see it (and probably wouldn't want to), so you really have no global dispatching point where you can put your own exception handler. your event handlers get called auto-magically by the code set up with the message map macros, and the code that actually processes the message map and dispatches messages is again inside the library.

I'm not sure off the top of my head if MFC has some sort of built-in exception mechanism that you can insert your own code into with some function calls, but if it doesn't then probably your only option is to catch exceptions at the event handler level (that is, don't let them propagate beyond OnCreate, OnPaint, etc.). Incidentally, when I wrote a wrapper class library of my own for the Windows API, I think I had problems with trying to put a global exception handler in WinMain and wound up having to put it in the window procedure -- in the case of a class library that uses virtual functions for message handlers that isn't a problem, though, because the window procedure can be pretty generic. that behavior still had to be built into my library, though, and I was able to do that because I had access to the message-dispatching code.

as for using TRY and CATCH versus try and catch, according to MSDN, the C++ exception mechanism (try and catch) should be used instead of TRY and CATCH in new applications. the TRY and CATCH macros evaluate to the C++ keywords and were provided by MFC 1.0, apparently before C++ had its own standard exception mechanism.

I've never tried to compile an MFC app in any other compiler, so I can't help you there.

I don't really know what to tell you about this whole exception business, except maybe look for a virtual function or something that you could override and then surround a call to the base class' implementation with a try/catch block. I'm not saying that any such thing exists, but it's about the only thing I can think of off the top of my head. I don't see anything about top-level exception handling in Prosise's book.

[ark]

just looked up CWinApp, and the Run method, which provides the message loop is overridable -- something like that may be your best bet

[ark]

actually, what you want is ProcessWndProcException, another CWinApp overridable

it would require that your exceptions all be CException-derived classes, however.