-
Notifications
You must be signed in to change notification settings - Fork 14
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
Minor language tweaks to x-parser error language #248
Comments
To discuss: if there are semantic implications for groups of numbers (e.g. 100-120 is a group) perhaps we should consider a more apparent group numbering scheme |
I was thinking that generally — we would have Within each group, I have no real opinion on the number allocations, but yes there are semantic differences. I tried to comment it in the code — I’ll repeat it here for reference: // Block #100-#119 — Invalid transition errors.
// Block #120-#139 — Common mistakes.
// Block #140-#149 — Forbidden transitions.
// Block #150+ — Special, named issues. (and the Invalid transition errors. This is a generic error when we cannot move the state machine forward and we don’t really have a great guess as to why we got stuck. We just know it failed and where. Common mistakes. This is a subroutine we run after getting stuck to try and pinpoint exactly why we think we got stuck. E.g., we first found we got stuck after a piece of “content” and then ran this subroutine to figure out that there is a malformed opening tag. Forbidden transitions. In this case we know exactly what the next transition is — but we specifically restrict it. Right now, only Special, named issues. We were able to parse the state transition, but then some other check happened. E.g., oh yah, we read your “attribute” and that’s cool, but unfortunately, you’re trying to set So “yes” is the short answer, there are definitely semantics there, but of course — I’m totally open to improving upon this stuff. |
FYI, I’m going to start using “start tag” and “end tag” as I’ve seen that in the specifications and it disambiguates usage of “open” and “close”. I.e., you can say some of the following things:
I know that’s minor — but then again… that’s what this ticket is all about 😅 |
Another thing you’ll see… I’m going to convert all these |
Taking on some of the language tweaks from #248. Also `switch`-ing on the values (versus using a `Map`) so that these cases can be enforced by code coverage. We likely have a couple messages which are impossible to get to. It’d be good to be forced to either remove them or find a way to prove that they are reachable via our test suite. For now, I reduced the coverage target to keep this change set smaller, but I will address that in follow-up efforts.
Taking on some of the language tweaks from #248. Also `switch`-ing on the values (versus using a `Map`) so that these cases can be enforced by code coverage. We likely have a couple messages which are impossible to get to. It’d be good to be forced to either remove them or find a way to prove that they are reachable via our test suite. For now, I reduced the coverage target to keep this change set smaller, but I will address that in follow-up efforts.
It's awesome that these are all wrapped up in this single lookup — thanks for that! I'll turn this into a PR soon... in the meantime I'm fiddling here in the ticket for some unknown reason (still in progress...)
On malformed vs invalid — I read this and I still don't know which term to use here!
The text was updated successfully, but these errors were encountered: