Dear Folks:
I am current working on a project involving trying to find the cause of some erratic behavior in an old Borland C++ 4.5 database application. Prehaps for obvious reason the orginal developer did not make use of exception handling. As for me,while trying to find the root cause of the problem I wish to (at the very least) use exception handlers as a debug tool. It is important therefore that I find a way to trap GPFs before they reach the fatal point. Nothing I have done thus far has offered me assurance that I can wrap suspected functions in try/catch blocks and expect the application to do anything except terminate with a GPF message. I'm i missing something here, or is my experience with modern system such as VC C++ jaded me into believing something that is not always true.
And so, a simple owl dialog based app is generated. A button is put on the screen that connects to code that is wrapped in a try/catch block. The button handler is intentioanlly coded to attempt a call function on a NULL pointer. I would expect that execution would jump into the nearest catch statement. NOT end up as a generalized GPF error dialog box--requireing a program restart.
I am currently using 5.02 because it was reported to have working exception handling. Now i am wondering if prehaps that 5.01 actually did throw unexcepted into the nearest catch(...). Before i revert to 5.01 is there anyone out there that can shed some light on this subject?
XP Pro
Borland C++ 5.01
16 bit application
BTW::The handlers work if i throw the exception myself. However, if i could afford to throw them, then i already know what i needed to kknow So.. i want to just allow the system to fault out and then record the information.
Thanks
JRC