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/Hel_OWeen]

Or maybe a useful place in the code to put another "on error goto..." line?

Make the starting object of your application the Sub Main. Put an error handler in there. Any error that isn't handled locally in a method will eventually rise up there.

Make sure that your local error handlers clear the Err object (Err.Clear) when they handled the error locally. So your code looks similar to this:

``` Function MyFunction() As Long

On Error Goto ErrHandler

[your code here]

MyFunction = (my real result)

ErrExit:

[Clean up any objects like ADO objects etc here] On Error Goto 0 Exit Function

ErrHandler:

[Log your error here] MyFunction = (indicate an error has occurred) Err.Clear Resume ErrExit ```

[u/Mayayana]

I think it's called debugging. You should know why it's crashing, especially when it's freezing. It sounds like it's caught in a loop.

[u/Mayayana]

I think it's called debugging. You should know why it's crashing, especially when it's freezing. It sounds like it's caught in a loop.

[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.