dherman
commented
5 years ago Some questions worth addressing:
- What should the approach to line lengths be? Should we have a fixed line length, or hard wrap based on the current console's dimensions?
- What sort of prefix should we use? e.g.:
error:Error:Notion error:- etc
- Note that it's important to include "Notion" for shim errors, to help the user understand that the error happened at a different context than the one that was probably in their mind at the time they were trying to execute the shim. For the
notiontool itself, including "Notion" in the prefix might look redundant.
- How should we use color/styling? I'd suggest it's helpful at least for the prefix to be red and bold, because it helps provide a more immediate signal to the user than the text itself, and also helps for scanning visually through a longer sequence of console output.
- Are there places where we it would be valuable for us to show context about an error? Notion isn't the same kind of product as a compiler, so many errors are more about e.g. filesystem issues. But maybe for things like invalid configuration files, it would be helpful to show some of the context surrounding the invalid file contents. This might be lower priority to implement than some of the other error improvements, but it might be good to call out in the RFC as a possible improvement.
Especially when considering some of these visual questions, some screenshots could be helpful to make the RFC more concrete.
Also, let me suggest one strategy for making progress on the prose style: you could do a first pass through the ErrorDetails enum, grabbing a set of maybe 5 - 10 errors that cover a reasonably diverse range of different kinds of errors, and try to develop specific error messages for each and include them in this RFC. That would help start to establish a prose style, and might help us to divide up the work on the remaining cases.
charlespierce
chriskrycho
rwjblue
Rendered