-
-
Notifications
You must be signed in to change notification settings - Fork 36
Split errors into their own section #593
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I started to nit-pick the text, but that's dumb. Let's hive off the text as-is first. I'm tempted to approve, but think we should address the error naming comment first.
@@ -43,7 +43,7 @@ Formatting of a _message_ is defined by the following operations: | |||
|
|||
At the start of _pattern selection_, | |||
if the _message_ contains any _reserved statements_, | |||
emit an Unsupported Statement Error. | |||
emit an _Unsupported Statement_ error. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should "error" be part of the error name as it is with other types of errors? We should be consistent. (I see this below with Unsupported Expression
and some others as well, but won't flag them pending discussion)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my first comment; the practice introduced here is to consistently include "Errors" in the category names, but not in the specific ones.
Co-authored-by: Addison Phillips <addison@unicode.org>
Closes #583
Conflicts a bit with #577 and #580, which will need to be updated.
The following naming styles are adopted and applied:
Effectively, categories include "Error", capitalized, but specific named data model & resolution errors do not. This is intended to help match error identifiers across implementations, and to make it convenient to present them together with their category, such as:
The sole named "Selector error" under Selection Errors is dropped, as it wasn't even referred to by that name in the formatting text.
The error handling section that was previously at the very end is moved up and slightly edited.