forums.silverfrost.com

[lozzer]

I am a non technical member of a software company, but provide support on our product.

From time to time users of our software report fatal exception errors when for instance the program has run out of resources such as graphics memory.

I am told by one of our developers that FTN95 is unable to trap such 'unexpected' errors, while most other development products do.

Is this the case or are we missing some functionality in the system?

Help would be appreciated.

Thanks.
_________________
Lozzer

[PaulLaidler]

Under Win32 (not .NET) you will find exception handling routines in the help file under FTN95 library->Error and exception handling.

The standard routine to use is TRAP_EXCEPTION@.

Having trapped an exception is it usually not possible to recover from this state (whether using FTN95 or not). The best you can do is save your data and exit gracefully.

[lozzer]

Thank you Paul. I'll check if we're already doing this much.
_________________
Lozzer

[lozzer]

That's worked a treat.


Thanks.
_________________
Lozzer

[Steve]

Thanks for the reference in the FTN95 manual.

Have attempted to use TE and sure enough the callback can get invoked. Unfortunately, a heck of a lot of calls are being made so by call GetLastError() values of zero are ignored.

What has now been happening is that unusual "errors" are causing the TE to be invoked. For example, after an OPEN of a direct accdess file the GetLastError() #183 ( "Cannot create a file when that file already exists" ) happens for no apparent reason.

In order to stop the TE reacting to the error the ALL_EXCEPTIONS setting cannot be used - in fact, only the ACCESS_VIOLATION seems to be the only TE setting to not force the callback.

Any advice / help ?

[PaulLaidler]

I would not use ALL_EXCEPTIONS. Some exceptions are benign.
Identify the particular types of exception that you want to trap and provide a handler for each one in turn.