While developing software in Snap! I often get error messages like:
What isn’t particularly helpful is the error message doesn’t indicate in which script the error occurred, making it harder to look for the cause.
So here’s my feature request:
Honestly I feel like it should show in which block the error is in, or where it was called, then if it's something like this example, instead of just the block that threw the error, show a bit more (and maybe highlight the block that threw the error).
Yes, I agree, there's a lot of work to be done in error handling. IIRC the situation was even a little better in BYOB, at the end.
There's a little UI design issue about what to do, though. Ideally, you'd like a Block Editor to pop open (although I think I've already lost Jens there) for each currently pending custom block, with the closest in front. But that could be a lot of popups, seriously cluttering the screen.
So instead perhaps there should be something like the slider in Time Machine that lets you move back and forth in time, with one window visible at a time. And in each Block Editor, the block where the error happened would be red-haloed. And maybe attached below each Block Editor would be a bunch of variable watchers for the parameters and script variables of this block invocation.
But also, the error message balloon (which should stick around until explicitly closed by the user) should include an upvar containing a continuation that the user can call (with a result value, if the block that errored is a reporter) to continue the computation as if the error hadn't happened.
And also, in single stepping mode, instead of just one resume button, there should be jump-over and jump-into, supposing you're paused at a custom block invocation.
So, yeah, a good error handling capability isn't something Jens can just throw together overnight.
‘The perfect is the enemy of the good”. IMAO you’re overcomplicating my request now. That won’t help @jens fulfilling it. KISS.
Yeah, okay. Then instead of asking for "a dump of" the environment, ask for the environment itself, as provided by THIS SCRIPT!
And maybe some forum kid would like to program in Snap! a block that interprets the environment into a list.
If I recall correctly, someone already did
Waiting for kids to arrive 
, a quick&dirty - call stack of the problematic block ...
May be used as an user script to form a private debug environment.
I love it! Make a PR and let's see if Jens loves it too. :~)
But I still want to see more than the block itself; I want to see the values of its inputs and script variables. Maybe by clicking on one of the block pictures in the error message. And also see a Block Editor window for that block... (Give me an inch and I'll take a mile.)
That's a nice stab a stack trace like view!
I think the real issue in Snap! is not that a stack trace it useful -- it def. is. But when. Too much info at once is overwhelming for folks, but I really like this idea.
I agree, this is simple, elegant, and a big step forward. The next step would be to make the block pictures clickable to present more information about a particular frame.
P.S. Did you do something to make Discourse do this really annoying fade-in of new posts?
I think that was just a discourse update, not anything custom.
The developers could add an option for "More specific errors" as a Shift menu or as a normal menu.
Settings menu:
☐ More error information
Option disabled hint:
check to see more details
about block errors
Option enabled hint:
uncheck to see only basic
details about block errors
for large scripts the error would take over the entire screen.
maybe a button to show the full script would be better.
The error dialog is "passive", i.e. it's the image of the complex morph not the "live" object.
To get the desired effect the separate UI must be created.
I agree that showing the complete script could swamp the actual error. Maybe a partial copy of the script with just the two blocks before the error?
About passive vs. live, is it possible to add a context menu to the error message? Then it could have a "show script" option (or open a Block Editor on it...).
I've tested a hand-crafted debug dialog (as a MenuMorph)
It's more compact, but the overall experience is that there are too many moving parts, and it chocks.
Yeah, the reason I keep asking about context menus is that you don't have to use them. The error message widget could still be just a passive picture.
I like seeing the call stack right away; it's usually pretty small. If the procedure that errors is a (non-tail) recursive function, so the call stack would include a zillion copies of the same block, it might be worth detecting that situation and including, say, the first two and last two (so that you could click on a menu to see their local variables) with an ellipsis in the middle. Or, easier but not quite as good, limit the depth of the displayed stack to five blocks or so.
this is getting ever more beautiful, Dariusz!
