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

[RFC] Unclear error messages #197

Open
Jens0512 opened this issue Jun 8, 2018 · 3 comments
Open

[RFC] Unclear error messages #197

Jens0512 opened this issue Jun 8, 2018 · 3 comments
Labels
semantics.interpreter Any issue relating to changing the semantics of interpreter code. semantics Generic label for semantics issues. All semantics issues should have this tag.
Milestone

Comments

@Jens0512
Copy link
Member

Jens0512 commented Jun 8, 2018

Have this code:

before = Time.now
sleep(Random.rand())
after  = Time.now

STDOUT.puts("Before - Milliseconds: <(before.milliseconds)>")
STDOUT.puts("After  - Milliseconds: <(after.milliseconds)>" )

And see it run:

$ myst test.mt
Uncaught Exception: No variable or method `milliseconds` for 2018-06-08 16:52:57:Time

The error in this program is that the method aimed for is Time#millisecond, as there exists no Time#milliseconds (with a trailing s).

The error message makes it clear that there is no variable or method milliseconds, – but for 2018-06-08 16:52:57:Time? At least to me, it seems very unlikely that 2018-06-08 16:52:57:Time would have any variables or methods at all. My point is that I believe using to_s in this situation can be very unclear.

Something like this would be good:

Uncaught Exception: No variable or method `milliseconds` for `before` test.mt:4
@faultyserver faultyserver added semantics Generic label for semantics issues. All semantics issues should have this tag. semantics.interpreter Any issue relating to changing the semantics of interpreter code. labels Jun 8, 2018
@faultyserver faultyserver added this to the Next milestone Jun 8, 2018
@faultyserver
Copy link
Member

I can agree with this. This style was taken from Ruby, which uses the format <instance>:<Class> when it outputs the receiver. In practice, this can lead to some really unwieldy output with objects that have a Scope that reaches the Kernel:

screen shot 2018-11-01 at 3 29 08 pm

(this is only part of the error output from a line that just reads assert(1).is_a(Object). The whole content of the Kernel ends up getting printed in the error message).

I think part of the need for Ruby's format comes from the fact that Ruby allows every object to act as a singleton, defining methods on the instance itself. Since Myst doesn't allow that, I don't think we need to follow the same format.

Getting the variable name for the missing value might be a little bit tricky, just because I don't think the interpreter has a way of knowing that at the point that the Call is looked up. It would be a worthwhile addition, though.

At least in the meantime (and probably in general), I would also recommend including the type of the receiving object in that output. I think that would help people quickly see if they just made a typo (e.g., "no method miseconds for variable before (of type Time)" quickly says "oh, i misspelled 'milliseconds'", vs "no method milliseconds for variable before (of type Object)" says "oh, why is before an Object here?").

tl;dr: I agree, but let's also add the type of the receiver to the output. I think your example should output something like:

Uncaught Exception: No variable or method `milliseconds` for `before` (of type `Time`) at test.mt:4

@Jens0512
Copy link
Member Author

Jens0512 commented Nov 1, 2018

Wow, that's quite some error-message.
And I love having such specific targets!

@Jens0512
Copy link
Member Author

Jens0512 commented Feb 1, 2019

Or maybe instead of ... for `before` (of type `Time`) ..., we can do:

... for `before:Time` ...

or even:

... for `before (Time)` ..

The one suggested by you definitely is the clearest one though

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
semantics.interpreter Any issue relating to changing the semantics of interpreter code. semantics Generic label for semantics issues. All semantics issues should have this tag.
Projects
None yet
Development

No branches or pull requests

2 participants