>>> More often than not, when I get something like a C0000005, it's the result of my incompetence, not VFP. <<
>
>I agree with your overall points but don't think that's a very good example. IMO VFP (or any other tool) should *never* cancel with a C5. Even incompetent code should be handled gracefully rather than blowing up.
>
>It goes without saying that any piece of software as large and comprehensive as VFP is going to have some bugs in it. You just expect them to be less spectacular than erroring out of the application.
>
Mike,

In theory, I agree with your point. In practice, under the Win32 environment, it's easier said than done because of the interdepencies of the various components of Windows. Even trying to isolate the cause of a C5 can be a very difficult proposition. Was it the video driver? The printer driver? And so on. This can make replication of the problem by the software team extraordinarily difficult.

Take the case of the problem mentioned in my post where I alluded to the change in behavior of VFP evaluating numeric overflow. The problem is that with certain printer drivers, they leave the state of the FPU in a way that expects the originating calling software (VFP) to handle exceptions caused by division by zero. This runs contrary to not only the DDK, but sound programming principles as well.

When this occurred the error message reported read:

"VFP caused an exception 10H in module VFP.EXE at < hex address >"

Simply reading the message indicates that it's a VFP problem. What's the root cause of the problem? It's not VFP, but the driver throwing the error back to it. If the driver is properly written, the error doesn't occur. Further, it doesn't occur if the application is written in such a way that the data is validated so that division by zero can't occur. Third on the list is VFP itself. It needed to be more fault tolerant and SP3 did that.

The point here is that this error could occur even in preview mode, because the printer driver is used in the rendering of the screen output also. However, because the video driver is involved as well, when trying to solve the problem that possibility has to be examined as well.

Thanks for the feedback.