So far, I have not gotten reports of FoxPro errors occurring in applications
I've distributed. I've gotten plenty in development to be sure, but I
haven't heard about those from users. Yet.

When that happens, is there anything I can do to control the box that pops
up saying things like "fatal error" and "FoxPro" and "Send report to
Microsoft"? I haven't decided exactly what kind of control I want over it,
but I'd like to know whether it's even possible.

Re: handling fatal errors at run time by Olaf

Olaf
Sat Dec 29 17:22:54 CST 2007

Hi Paul,

there's a chapter on error handling in the help
that's more verbose than what I can write here.

But in short, you can write an
ON ERROR
handler that would handle all errors, you can
handle error locally by
TRY..CATCH..FINALLY..ENDTRY
and you can use ERROR() events in most
objects.

If the error occurs, values of
ERROR(), MESSAGE(), MESSAGE(1), LINENO(),
LINENO(1) and POGRAM() are helpful,
but you can get most of these infos also

with AERROR() and with ASTACKINFO().

You could put all these infos in a cursor,
cursortoxml the data and send that to you
via mail or at least store it in an error table.

Then you can cancel, return or retry with
CANCEL
RETURN
or
RETRY

Take a look here:
http://fox.wikis.com/wc.dll?Wiki~ErrorHandling~VFP

Bye, Olaf.

Re: handling fatal errors at run time by Paul

Paul
Sat Dec 29 20:00:56 CST 2007

I guess I didn't make myself clear. I'm talking about C0000008-style errors.


"Olaf Doschke" <olaf.doschke@t-aufderlinie.de> wrote in message
news:eEVDAHnSIHA.3864@TK2MSFTNGP03.phx.gbl...
> Hi Paul,
>
> there's a chapter on error handling in the help
> that's more verbose than what I can write here.
>
> But in short, you can write an
> ON ERROR
> handler that would handle all errors, you can
> handle error locally by TRY..CATCH..FINALLY..ENDTRY
> and you can use ERROR() events in most
> objects.
>
> If the error occurs, values of
> ERROR(), MESSAGE(), MESSAGE(1), LINENO(),
> LINENO(1) and POGRAM() are helpful,
> but you can get most of these infos also
>
> with AERROR() and with ASTACKINFO().
>
> You could put all these infos in a cursor,
> cursortoxml the data and send that to you
> via mail or at least store it in an error table.
>
> Then you can cancel, return or retry with
> CANCEL
> RETURN
> or
> RETRY
>
> Take a look here:
> http://fox.wikis.com/wc.dll?Wiki~ErrorHandling~VFP
>
> Bye, Olaf.



Re: handling fatal errors at run time by Paul

Paul
Sat Dec 29 20:37:18 CST 2007

Just got another one:

Microsoft Visual FoxPro has encountered a problem and needs to close.
We are sorry for the inconvenience.




"Paul Pedersen" <nospam@no.spam> wrote in message
news:enq5QfoSIHA.4196@TK2MSFTNGP04.phx.gbl...
>I guess I didn't make myself clear. I'm talking about C0000008-style
>errors.
>
>
> "Olaf Doschke" <olaf.doschke@t-aufderlinie.de> wrote in message
> news:eEVDAHnSIHA.3864@TK2MSFTNGP03.phx.gbl...
>> Hi Paul,
>>
>> there's a chapter on error handling in the help
>> that's more verbose than what I can write here.
>>
>> But in short, you can write an
>> ON ERROR
>> handler that would handle all errors, you can
>> handle error locally by TRY..CATCH..FINALLY..ENDTRY
>> and you can use ERROR() events in most
>> objects.
>>
>> If the error occurs, values of
>> ERROR(), MESSAGE(), MESSAGE(1), LINENO(),
>> LINENO(1) and POGRAM() are helpful,
>> but you can get most of these infos also
>>
>> with AERROR() and with ASTACKINFO().
>>
>> You could put all these infos in a cursor,
>> cursortoxml the data and send that to you
>> via mail or at least store it in an error table.
>>
>> Then you can cancel, return or retry with
>> CANCEL
>> RETURN
>> or
>> RETRY
>>
>> Take a look here:
>> http://fox.wikis.com/wc.dll?Wiki~ErrorHandling~VFP
>>
>> Bye, Olaf.
>
>



Re: handling fatal errors at run time by swdev2

swdev2
Sat Dec 29 21:14:05 CST 2007

As Usual, Calvin's at it again:
http://blogs.msdn.com/calvin_hsia/archive/2006/12/07/customer-question-what-
does-the-crash-call-stack-mean.aspx

But he doesn't really go on about 'trapping' Dr. Watson's error handling
stuff.

Cristof has a good approach (similar to what Olaf is trying to tell ya) over
at
http://my.advisor.com/doc/19193?open&p=1&pid=

but it doesn't cover trapping Dr. Watson calls.

hth - Regards [Bill]

--
===================
William Sanders / EFG VFP / mySql / MS-SQL
www.efgroup.net/vfpwebhosting
www.terrafox.net www.viasqlserver.net

"Paul Pedersen" <nospam@no.spam> wrote in message
news:#e0cWXkSIHA.5160@TK2MSFTNGP05.phx.gbl...
> So far, I have not gotten reports of FoxPro errors occurring in
applications
> I've distributed. I've gotten plenty in development to be sure, but I
> haven't heard about those from users. Yet.
>
> When that happens, is there anything I can do to control the box that pops
> up saying things like "fatal error" and "FoxPro" and "Send report to
> Microsoft"? I haven't decided exactly what kind of control I want over it,
> but I'd like to know whether it's even possible.
>
>
>
>



Re: handling fatal errors at run time by Olaf

Olaf
Sun Dec 30 03:16:55 CST 2007

Hi Paul,

>I guess I didn't make myself clear. I'm talking about C0000008-style
>errors.

I have some C0000005 sometimes. Mostly during
development. You have no chance handling these
with a vfp error handler, these are happening in the
vfp runtime module, so really vfp crashes.

The CX message itself can also be found in a vfpXerr.log
So an easy way to get at this info is storing that log
file in some error table or sending this via mail.

Mostly it's still no vfp bug, but your code wasn't handling
object destruction correctly, so you have a half dead object
and some object reference pointing to a dead object, which
may cause acccess to memory having been freed and not
belonging to our process anymore. See what Bill has linked
to Calvian Hsias blog, he's using Sys(1079) to intentio-
nally crash the system.

If it's not dangling object references, mostly it's graphic
driver issues, printer driver issues, corrupt frx, dbf, dbc,
anything that makes the vfp9r.dll access restricted area
and thereby causing an error exception.

With C5 or C8 or errors of that range, you need to
handle that on the C++ level, remember vfp is programmed
in C++, Calvin talks about dynamically attaching a debugger
and has some additional articles.

Bye, Olaf.