When the app running in the IDE throws an exception and I click on the console, the editor opens with the linked line selected (good) and the app stops (bad).
In the old editor the app had to be stop in order for the editor to be visible.
In the new editor the app runs on the side of the editor or in another tab, so there is no need to stop it.
I often click one button, see the traceback, click on it to see the where the problem is, then I want to check if the same happens when clicking on another button, but it is impossible because the app stopped.
In the debuggers I’m familiar with, stopping is generally a good thing.
With the app stopped, you can inspect the function’s local variables at the point where the exception occurred. (Use the Python Console to print values, etc.) This way, you can learn more about the circumstances, i.e., how and why the exception occurred.
If the app kept running, then the local stack frame, with its variables, would be cleaned up (erased), and that valuable information would be lost.
You can get the best of both worlds, if the developer has the option to resume the program.
Anvil doesn’t allow to inspect variables. All you can do is click on the links that take you to the editor.
Some errors prevent the app from continuing its job, so you can’t use the app after the error anyway, but some errors only prevent one button from doing its job, and if you have many buttons that you can test without restating the app and clicking your way to the crashing condition, keeping the app running can be useful.
On the other hand, stopping the app with the new editor, where you could click on the traceback and jump to the editor while the app is still running, is never useful.
I think the current behavior is to stop the app only because the old behavior was to stop the app, not because that’s the best thing to do.
Actually (as of a few days ago), I was able to inspect variables after an exception in the Beta console (by typing something like get_open_form().button_1.text). The app didn’t stop running until I clicked on a traceback link to go to the specific line in the editor.
It does seem like the stop/resume model for debugging would be optimal, though.
