-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Add descriptive error messages to unwrap()s #593
Comments
Lowering priority since this is not very impactful in practice. |
Is this just a case of replacing the |
Hi @cmannett85, we do not have formal requirements for formatting error messages. We do however try to keep them short and clear and also try to reuse the same static strings so that we minimize the binary size. For example most This issue is indeed a case of replacing |
I've made the changes I think are required, but I've hit across an unexpected issue. Because I've added an error string, this has pushed some lines over the column limit for the rust style, so
What do I do? I haven't made any changes that warrant new unit tests. |
@cmannett85, did you ever get a response, or did these changes land? |
Yes, they're in the PR listed above. |
@iulianbarbu makes a good point re user guidance: I wonder if the approach of rustc and various linters can be adopted, where a error 'code', FC001, is returned with a url setting things out in more detail? This way the error messages are not burdened by having to tell a sensible/useful "story" about what went wrong when these messages are read in context/sequence. All that context and detail can be set out at the URL A further advantage of this is these error strings are kept brief and that can help relieve the overhead in tracing contexts where a error message is recorded in a span field. |
We've discussed this with the team today, and decided to close this issue without further action. The preferred way to handle user-facing errors is by propagating them all the way up to |
There are remaining
unwrap()
s in the code that cannot be avoided, which lead to a not-so-user-friendly error message being printed. All such failure cases should print a descriptive message along with the panic location.The text was updated successfully, but these errors were encountered: