Variables only lose their value only when the VBA project is reset. Unfortunately there is a persistent myth that they lose their values in an unhandled exception.
I think their introduction was also about making VBA variables available in queries. Of course this can also be done with a function. I consider TempVars to be "a solution looking for a problem" and have never used them.
I found this response interesting. Throughout reading this thread, I was thinking to myself "I never use TempVars, but I wonder if I should admit that" (ha ha).
Now I feel more comfortable doing so. I also felt that way about a solution looking for a problem. To this day I still use global or public variables when necessary, and haven't really noticed any downside of doing so. I've never been sold on why TempVar is better, and never felt I had a need for it, so have never used them.
As for unhandled errors, I never really knew if that was true or not, but didn't care too much since error handling is a top priority for me. Good to know.
One of the things that turned me off about them is that they are advertised as too much of a "You can do anything you want with this thing, without understanding anything about anything". Any time I see something like that, I hesitate to use it, because I feel it doesn't do me any favors, but rather encourages me
not to learn the necessary programming concepts that are inherently required (more so) to use the other stuff. This last bit is very personal, though, and admittedly might "just be me".
Edit:
@Galaxiom As I'd like to master this question once and for all, can you check out the attached and let me know why the global var appears to lose its value after the unhandled error? I think the answer is, "
because when I pressed END to the unhandled error, that reset the VBA project", but then my question would be, practically speaking in real life, isn't that would almost every user would do, if Continue wasn't an option?