Handle parsing errors in moo.states()
See original GitHub issueHi,
I’m looking for a way to get the offending in a moo states object. The following doesn’t seem to work and a regular error is still thrown:
moo.states({
main: {
// throws the error instead of tokenizing it
myError: moo.error
},
// This throws a moo configuration erro
myError: moo.error,
});
What would be the correct way to get the error or offending token in a stateful lexer?
Issue Analytics
- State:
- Created 5 years ago
- Comments:8 (3 by maintainers)
Top Results From Across the Web
Error handling · Issue #18 · no-context/moo - GitHub
It returns many lines, making the resulting message hard to read. It leaks the entire buffer (thanks to V8's implementation of slice() using ......
Read more >no-context - Bountysource
I'm writing a parser that uses moo as a lexer. In certain situations, it would be highly beneficial to have access to the...
Read more >How to handle parser errors - json - Stack Overflow
I'm writing a JSON parser and I have trouble coming up with good design for the error handling. Let's say that at some...
Read more >Declarative parse error reporting with Menhir - Daniil Baturin
However, the new way of error handling doesn't work with the classic yacc-like ... The 'a I.checkpoint is the type of the parser...
Read more >nearley - npm
Simple, fast, powerful parser toolkit for JavaScript. ... nearley also has capabilities to catch errors gracefully, and detect ambiguous grammars (grammars ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
That only works for me if I have another token type in the list; otherwise it generates the regex
/(?:)/my
and then fails when it can’t find the group that matched. If there are no tokens that match anything, instead of generating/(?:)/
(an irrefutable match), we should generate/(?!)/
(an impossible match).I think it might. Usually lexer states are opaque to the parser and it just sees a stream of tokens, so you very rarely want a) only certain states to have error tokens or b) different states to have different names for the error token. But I don’t think the syntax @moranje provided makes sense—if we go this route, we should probably have a more general notion of state inheritance and/or a special state from which other states automatically inherit; then a global error token would be as simple as a
{ myError: moo.error }
prototype state.Great! I have limited time to spare at the moment, but am excited to try out these additions. I’ll try to implement the changes somewhere this week. I’ll get back to you on this, great work!