Detailed error reporting for corrupted error depth #14
Conversation
Split the one case reporting about corrupted *maximum-error-depth* or corrupted *current-error-depth* into two cases, in order to be able to know which is actually corrupted.
|
i'm wondering how this is useful and why it should be included. i mean, the error message is unique and leads to the source code, that in turn leads to the two relevant special variables, which then should lead to the code that actually corrupts them, which should be fixed as a bug. do you still think this patch a worthy increase of complexity? |
|
I'm not sure whether it's worth including. I opened this pull request because it seems that the changes are in the repository but possibly "lost". Also it's been a while since I worked on this issue. From what I remember I was not able to tell which of those two variables was corrupted without this patch. I cannot say to what extend this was because I'm just unfamiliar with sbcl internals or because it's really hard. IMO the patch does not significantly increase complexity, thus I would include it. But I doubt it will do any harm if its not included either :) |
I just stumbled over this (old) change of mine that helped debug an error someone on stackoverflow.com was having with sbcl. It provides a little more detailed information about which error-depth is corrupted (maximum or current).
I don't know whether I already reported this, as it seems to be in the sbcl/sbcl repository: bce3b98
The above looks like a "headless" commit, and the changes are not present in current master, thus this pull request.