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

"index out of bounds" error shouldn't exit REPL #138

Closed
brianhuffman opened this issue May 25, 2016 · 5 comments
Closed

"index out of bounds" error shouldn't exit REPL #138

brianhuffman opened this issue May 25, 2016 · 5 comments
Labels
bug priority usability An issue that impedes efficient understanding and use
Milestone

Comments

@brianhuffman
Copy link
Contributor

For example:

sawscript> print {{ [True]@2 }}
saw: at: index out of bounds

The REPL then exits to the command prompt. It should instead return to the REPL prompt.

@brianhuffman
Copy link
Contributor Author

Part of the problem is that some of our primitives have a single implementation that runs in a different monad depending on the backend (Identity for concrete evaluation, IO for SBV and ABC). If a primitive uses fail to report an error, this turns into an IOException in IO, but it turns into a call to error in Identity (which raises an asynchronous exception). This makes it more complicated to catch the errors in each case, since we can't use the same method for both.

@atomb
Copy link
Contributor

atomb commented May 3, 2017

Can we use some sort of error-tracking monad instead of Identity for concrete evaluation?

@atomb atomb added this to the 0.3 milestone Feb 5, 2018
@eddywestbrook
Copy link
Contributor

A simpler idea, that would require less change to the simulator(s), would be to have errors in the simulator throw a new type of Exception, maybe a SimulatorException or something like that. The idea would be that error should really be reserved for unrecoverable failures, but things that are recoverable at the REPL, like having an index that is too large, should use a different mechanism.

Thoughts?

@atomb
Copy link
Contributor

atomb commented Sep 17, 2018

I would take that one step farther and say that even totally unrecoverable things could use some custom exception so that we can give good error messages, even if we can't otherwise recover. Also, @kwf has been giving some thought to this topic, and I'd be interested in their input.

@atomb atomb removed the maybe-fixed label May 21, 2019
@atomb atomb modified the milestones: 0.3, 1.0 May 21, 2019
@atomb atomb modified the milestones: 0.5, 0.6 Apr 27, 2020
@atomb atomb added the usability An issue that impedes efficient understanding and use label Apr 28, 2020
@atomb atomb modified the milestones: 0.6, 0.7 Aug 31, 2020
@brianhuffman brianhuffman removed their assignment Dec 4, 2020
@atomb
Copy link
Contributor

atomb commented Dec 14, 2020

This specific case no longer causes the REPL to exit (and I think many other failures should be fixed along with that). I think #870 captures the remaining work to be done.

@atomb atomb closed this as completed Dec 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug priority usability An issue that impedes efficient understanding and use
Projects
None yet
Development

No branches or pull requests

3 participants