Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Internal errors are not just impossible executions #2106

Open
sauclovian-g opened this issue Aug 24, 2024 · 2 comments
Open

Internal errors are not just impossible executions #2106

sauclovian-g opened this issue Aug 24, 2024 · 2 comments
Labels
needs test Issues for which we should add a regression test tech debt Issues that document or involve technical debt topics: error-handling Issues involving the way SAW responds to an error condition topics: error-messages Issues involving the messages SAW produces on error usability An issue that impedes efficient understanding and use
Milestone

Comments

@sauclovian-g
Copy link
Collaborator

In general when all branches of execution become impossible, and you were not intending that, it's hard for a computer to tell which of them are impossible because they should be impossible and which are impossible because there's something wrong with your spec.

Therefore in this case saw prints what stopped each one. AIUI; at least, that's what appears to happen.

Currently, if some branches of execution crash (cause internal errors in saw, step on unsupported operations in crucible, etc.) those are apparently treated as impossible branches rather than as immediate errors, and so it's possible to get a report about such a problem combined with other entirely unimportant or bogus reports about non-matching overrides or other things in other branches.

This shouldn't be done that way. Not only are the reports on other branches of execution generally confusing, it's quite easy for a naive user to go on a wild goose chase investigating them in detail.

I think there must not be enough granularity in failure tracking somewhere.

(Also I hope that if one branch of execution crashes and others succeed that we aren't accidentally suppressing the crash message as if it's a routine false branch. That could turn out to be a pretty serious soundness problem.)

@sauclovian-g sauclovian-g added topics: error-messages Issues involving the messages SAW produces on error usability An issue that impedes efficient understanding and use tech debt Issues that document or involve technical debt topics: error-handling Issues involving the way SAW responds to an error condition labels Aug 24, 2024
@RyanGlScott
Copy link
Contributor

It would be helpful to distill a relatively self-contained example of this behavior happening.

@sauclovian-g
Copy link
Collaborator Author

No disagreement there 😐

@sauclovian-g sauclovian-g added this to the 2025T1 milestone Nov 8, 2024
@sauclovian-g sauclovian-g added the needs test Issues for which we should add a regression test label Nov 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs test Issues for which we should add a regression test tech debt Issues that document or involve technical debt topics: error-handling Issues involving the way SAW responds to an error condition topics: error-messages Issues involving the messages SAW produces on error usability An issue that impedes efficient understanding and use
Projects
None yet
Development

No branches or pull requests

2 participants