Skip to content

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

Merged
merged 3 commits into from
Jan 15, 2024
Merged

Split errors into their own section #593

merged 3 commits into from
Jan 15, 2024

Conversation

eemeli
Copy link
Collaborator

@eemeli eemeli commented Jan 12, 2024

Closes #583
Conflicts a bit with #577 and #580, which will need to be updated.

The following naming styles are adopted and applied:

  • Syntax Errors
  • Data Model Errors
    • Variant Key Mismatch
    • Missing Fallback Variant
    • Missing Selector Annotation
    • Duplicate Declaration
    • Duplicate Option Name
  • Resolution Errors
    • Unresolved Variable
    • Unknown Function
    • Unsupported Expression
    • Unsupported Statement
  • Selection Errors
  • Formatting Errors

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:

Resolution Error: Unknown Function

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.

@eemeli eemeli added documentation Improvements or additions to documentation editorial Issue is non-normative specification Issue affects the specification formatting Issue pertains to the formatting section of the spec LDML45 LDML45 Release (Tech Preview) labels Jan 12, 2024
@eemeli eemeli requested a review from aphillips January 12, 2024 19:59
Copy link
Member

@aphillips aphillips left a 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.
Copy link
Member

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)

Copy link
Collaborator Author

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation editorial Issue is non-normative formatting Issue pertains to the formatting section of the spec LDML45 LDML45 Release (Tech Preview) specification Issue affects the specification
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Hive off the errors section and data model materials from formatting.md
2 participants