In class today I ran across an extremely-difficult-to-reproduce error which nevertheless comes with an error message that might make it possible to repair anyway.
Here's a screenshot, showing a program and the result of running Run:
Reading this error message suggests that the parameter's guard wants infinity to be represented as 'infinity, not as +inf.0, which makes it sound like an easy fix. However, taking a look at the error location in rep, I see that it's setting the parameter with a value that appears to be derived from an earlier capture of the parameter's value, so it's not clear how the parameter is getting the bad value in the first place.
Anyone else seeing this? I think it's possible that the error is related either to the very large font size, or to a separate internal error that cropped up later, alas.
The function reset-pretty-print-width (in that same file) is apparently getting an infinity somehow. I guess that width is infinity coming out of get-view.
It seems straightforward to add a guard that caps the pretty-printing width at some large number I suppose, but probably there is a bug elsewhere that's making get-view do the wrong thing?
I'm thinking about this harder now, and I think that the key problem for me was that the error was presented as a bug in my program.
That is: I'm standing in front of the class, I'm seeing red text, and I'm thinking "oh gee, there's a bug in my program, what the heck is it?". For contrast, when I see a DrRacket internal error, I know that it's not my fault, and I can do routine things like restarting the IDE.
So I guess I want to ask another, different question: is there an easy way to make this an internal error instead of a user error? It might be difficult to adjust the boundary between student code and IDE code in that way.
I experimented with some code to try to do this for code that is running on behalf of the user long ago and it ended up being a lot easier to just try to fix the bugs (especially when the bugs might be in the IO parts). Overall, it got too complicated and it was causing bugs of its own. In contrast, when code is running in the drracket eventspace, well, all of the possible errors are bugs in DrRacket.
In this case, one thing we could do is add a check to make sure that get-view's width is reasonable and raise an internal error. That might even move the timing of the error in such a way as to get a hint as to how to reproduce too.
