I think what is referred to here is that an exception doesn't unwind the stack. Even if the exception is uncaught, you can fix the line or value and then resume where the stack was.
Visual Studio has done this since the 90s for C++ code (and C# code for a good while also, just most people have debugger exception catching turned off).
How I know? Back in 2000-2001 we were working on a Dreamcast game with a 3dfx/Glide PC renderer, that 3dfx driver on WinNT was unstable and crashed the machine every 3rd-5th start of the game so being able to edit-continue was a damn lifesaver since a lot of common tweaking of custom stuff outside of what connected to the scripting system could be done at runtime.
This is one thing I think so makes people loyal to MSVC despite it having been behind on standards (gonna be interesting to see if they get reflection up to speed for the 2027 release, GCC's there but not yet Clang).
The leave instruction is required to exit a try, catch, or a filter block. At least last time I read the spec (which is a while ago, but still).
See https://news.ycombinator.com/item?id=23844283 for examples on CL.
No, the debugger (when using Visual Studio proper) breaks at the point of throwing (be it an explicit throw or something underlying like a NPE or out-of-bounds access), _I_ literally use this _all_ the time to fix code while in motion (set next statement on a line a bit back or even the same line to rewind just a tiny bit, change the code, fix errant variables, press F5 to continue and the IDE will rebuild and reposition instruction pointers and update stacks).
What the spec says about execution semantics of exceptions is one thing, what capabilities the debugger provides can be something entirely different.
Perhaps VSCode or some other environments don't have as good debuggers, but trust me when I say that it allows you do do exactly what you need.
Someone saying something in a comment doesn't negate a capability that person doesn't know about.
I don't see it print the "here" line in their example.