Closed easyas314159 closed 2 years ago
Thanks, @easyas314159, yes, this is not ideal. Most likely a result of me trying to be too clever in the parsing/exception logic in parser.py
. The recursive nature of nested blocks doesn't help, either.
It may take me a few days to get to this.
@rbeyer If it would help I'll have some time today or tomorrow and can write unit tests for this case
I'm not gonna say no when someone volunteers to write unit tests.
It could help, but ultimately we need to untangle the nested logic of exceptions and figure out why the parser keeps going (and then runs out of tokens with StopIteration) even after it gets that LexerError that should stop everything.
Ah, I figured it out. I added a simplified version of your level1 example that performed as expected and your level2 to the test_parser.py unit test. Turns out I need to remember that our LexerErrors are derived from ValueErrors, so if we're in a situation where both specific LexerErrors can get emitted or regular ValueErrors, and we want to do something different depending on which happens, I also need to catch the LexerErrors.
Looks like there are some shenanigans going on with the GitHub backends, so the tests aren't running, but I'm hoping that'll clear up on its own.
This fix is now merged into main, and will show up in the next release.
Describe the bug Lexing errors in nested object blocks are being masked by a StopIteration exception.
To Reproduce
example.py
LEVEL1.LBL
LEVEL2.LBL
Expected behavior
Error logs or terminal captures
LEVEL1.LBL
LEVEL2.LBL
Your Environment (please complete the following information):
pvl
Version: 1.2.1 and 1.3.0Additional context None