-
Notifications
You must be signed in to change notification settings - Fork 17
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
Only raise RuntimeError
s from the Interpreter
#98
Labels
good first issue
An issue that provides a good intro to working with the Myst codebase. Be helpful!
spec
An issue with relating to the specs around the Myst codebase (native or in-language).
Milestone
Comments
faultyserver
added
good first issue
An issue that provides a good intro to working with the Myst codebase. Be helpful!
spec
An issue with relating to the specs around the Myst codebase (native or in-language).
labels
Dec 26, 2017
This was referenced Dec 29, 2017
faultyserver
added a commit
to faultyserver/myst
that referenced
this issue
Dec 30, 2017
…to RuntimeErrors, move nativelib specs into Myst. This commit starts work on converting all errors raised by the interpreter into rescue-able RuntimeErrors. Specifically, this commit addresses all instances of `raise` in the Native Library, using the new `__raise_runtime_error` to raise an appropriate message. When myst-lang#103 is addressed, these errors will change to proper error structures (rather than strings), but that is a future effort. Some other instances of `raise` were also converted in the process of this commit.
faultyserver
changed the title
Improve exception types used for
Raise only RuntimeErrors from the Interpreter
Jan 1, 2018
expect_raises
.
faultyserver
changed the title
Raise only RuntimeErrors from the Interpreter
Only raise Jan 1, 2018
RuntimeError
s from the Interpreter
faultyserver
added a commit
to faultyserver/myst
that referenced
this issue
Jan 1, 2018
By making MatchError a descendant of RuntimeError, it can be rescued inside the language itself. This is one more step to making the interpreter only raise RuntimeErrors. The matcher specs needed a fair bit of reworking to play nicely with this change, including a change to `Interpreter#run` that tells the interpreter to allow errors to propogate farther up and be expected by the specs.
faultyserver
added a commit
to faultyserver/myst
that referenced
this issue
Jan 6, 2018
…rom `Scope#[]`. It's a bit of a cop-out solution, but the idea is that `IndexError`s raised by `Scope#[]` should not happen anywhere in the interpreter. Any case where the key may not be present should be guarded against appropriately. As such, if the `IndexError` propogates to outside of the Interpreter, it should be considered a bug to be fixed, as the messasge of the error now indicates.
faultyserver
added a commit
to faultyserver/myst
that referenced
this issue
Jan 6, 2018
…_literal` raise case. Any attempt to create a Value from a Node should guard that the Node is a Literal type. Attempting to create a Value from a non-literal type should be considered an Interpreter bug and addressed as such.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
good first issue
An issue that provides a good intro to working with the Myst codebase. Be helpful!
spec
An issue with relating to the specs around the Myst codebase (native or in-language).
This issue has been marked as a "Good First Issue"! If you'd like to tackle this issue as your first contribution to the project, be sure to read the Get Involved section of the README for some help with how to get started.
With the upgrade to Crystal 0.24.1 (see #53),
expect_raises
now requires an exception type to be specified by the callers. Out of haste to get 0.3.0 out, I've just put the generalException
class in for most cases where no argument was given. However, this is not a good practice, and the expected exceptions should be better restricted to more relevant types.I think this improvement has two components: First, find all instances of
expect_raises(Exception)
in the spec suite and change them to more appropriate types (e.g.,ParseError
for errors raised by the parser,SyntaxError
for errors from the Lexer, etc.). I don't think there are many of these.Most instances probably won't be resolvable by the above fix, so the second part of this improvement would be to find all instances of
raise
in the Interpreter source code and turn them into appropriateRuntimeErrors
. Not only does this help improve the spec, it also means that users can catch these errors in their programs, which is a good goal.Adding a
__raise_runtime_error
helper method toutil.cr
also seems like a good idea to help mitigate the risk of this issue coming up again in the future.Here's an example of how one of these improvements could be made. Line 18 here raises a native exception when re-assigning the value of a Constant:
myst/src/myst/interpreter/nodes/simple_assign.cr
Lines 16 to 21 in 4065100
Instead of a native exception being raised, I think this should raise a
RuntimeError
with the same message. Assuming the__raise_runtime_error
method from above is implemented, it might look something like this:Then, in the specs, there's this test:
myst/spec/interpreter/nodes/simple_assign_spec.cr
Lines 29 to 35 in 30be440
that should change to expect a
RuntimeError
instead of a normalException
.Hopefully that's enough direction to get started. As always, feel free to ask any questions either here or in the discord server. I don't think this issue requires too much knowledge of the interpreter, but it's hard for me to tell.
The text was updated successfully, but these errors were encountered: