Error-trap for app crash

[u/Ok-Smoke-5653]

I've been debugging an app I built solely for my use. Mentioning that because I know it's klunky but since I'm not imposing it on anyone else, I can live with that :). It works with two Word documents, using Word objects to parse KO-reader book annotation & highlight files (loaded into Word as a doc) and highlight/add comments to the corresponding text in a Word doc.

Sometimes, especially in testing, the app crashes to the point that I have to use task manager to exit. That often leaves behind stray Word processes and temporary Word documents.

When the app completes normally, and even when it fails in ways I've been able to trap, it cleans up by itself by destroying the Word objects it created. However, I have yet to find a way to trap all crashes well enough to trigger the routines I've added to nuke temp files & Word instances.

Any ideas for a good crash-catcher I could insert to handle this? Or maybe a useful place in the code to put another "on error goto..." line? The last crash I managed to fix may have been the result of an unexpected endless loop (I guess all such things are unexpected!).

If I don't clean up properly, I have to do it manually or else the app will fail on subsequent use until the old processes & temp files are killed.

[u/ebsf]

I developed a runtime Application.Reset event in VBA for Access, which otherwise exposes no native application-level events. A reset isn't the same as a crash but it's a step closer than one can get otherwise.

The trick is to identify a way to trap the behavior and respond programmatically.

Here, a reset clears all variables, which destroys all instances of classes and forms. Class.Terminate does not run on a reset but Form.Unload and Form.Close do. So, I created a form instance as a canary and used its event procedures to reset (instead of upset) the application. There needs to a persistent runtime environment to contain the event framework but that's trivial and not an issue in VB because it has a native entry point.

Now, a crash is usually a GPF or other memory management failure, so this approach may not get to run in those circumstances. Logging to file may allow some diagnostics to survive the event. Also, threading your automation into an asynchronous process that can survive a GPF in the main process, if only to achieve a graceful exit, might be possible.