-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
more verbose, friendly error messages #36865
Comments
There are at least two things you can do in an error message: describe the problem and provide hints about how to fix it. The second is attractive but the first is much safer, and it's likely that only the first is always possible. So as a first pass I would focus on trying to come up with less jargon-heavy ways of saying the same thing. I've long meant to do the same thing to the manual (which has some very newbie-friendly sections but some that are not), but that's a big task and it hasn't yet risen to the top for me. |
For syntax errors, what about giving every error a unique type or a short unique string (e.g. I'm not happy with the hints of Rust's linter (clippy), but I think its ecosystem itself is great. |
Taking off the milestone. |
Somewhat better now:
Still likely we should do a lot more to make our errors better, but this issue doesn't have an actionable list. |
A lot of the error messages in Base are carefully worded to fit on a single line. This often comes at the cost of them being pretty inscrutable to new users. I'd like to propose a systematic effort to lengthen and clarify our error messages. There are many examples, but I was prompted to open this issue by this post on StackOverflow:
https://stackoverflow.com/questions/63188794/difference-between-fsstring-and-fstring
The question is not about inscrutable error messages, but the answer includes this error message:
I know what that means, but, man, that's not going to make sense to most people 😬. What's the best strategy for making all our error messages easier to understand for people who aren't deeply steeped in Julia development?
The text was updated successfully, but these errors were encountered: