You're right - there are possibilities here that I've been thinking about since my post.
There are several separate problems to overcome:
1. Spotting the labels
You have come up with one solution - it requires a pre-processor, or a lot of manual setting up. There's a cleaner alternative that would use a combined pre/post-processor too. So it's doable, but not clean and requires a separate program to be run as a part of the compilation.
2. Jumping to the labels
Goto - easy-ish (remembering to keep the stack clean).
Gosub - Dunno - is there a separate gosub stack? If not then it's a slightly harder variation of the goto jump.
resume - where does the 'current' line start so you can resume it?
resume next - as per goto.
Call function - as per goto.
In all of the above, how is the stack affected by the error and what recovery is required? What about nested function calls or multiple gosubs?
3. Capturing the error before it triggers the runtime shutdown.
Doable - there's a section of error-handling code at the end of each compiled line where I can replace the code with my own.
4. Runtime discrepancies.
Who knows how much of a problem this is...
Load an object, runtime creates it and starts populating it, hits an error condition ... does it fully clean up the object and temporarily allocated memory,, or leave it all as-is, knowing that the program is going to shut down and will clean up anyway?
If you assume that the program is going to end, why would you write the code to clean up (more code = more bugs)? I would assume that you wouldn't.
Then we come along and try to change one of those basic assumptions ...
So, there are problems that are simple, some not so simple but doable, and some I can have no impact on at all. I'll continue to think about it, but I'm not sure it's a solvable problem without a lot of Lee or Mikes help (or access to the DBPro source code)