question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Handle parsing errors in moo.states()

See original GitHub issue

Hi,

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:open
  • Created 5 years ago
  • Comments:8 (3 by maintainers)

github_iconTop GitHub Comments

2reactions
nathancommented, Aug 18, 2018

The following works fine for me:

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 don’t think it would make sense to allow configuring an error at the toplevel?

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.

0reactions
moranjecommented, Sep 20, 2018

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!

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found