-
Notifications
You must be signed in to change notification settings - Fork 201
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
Throw, if BlockSyntax.parseLines
loops indefinitely
#533
Conversation
We throw an `AssertionError` if `BlockSyntax.parseLines` enters an infinite loop. This should have no effect, if there are no bugs. But if there is a bug, it's easier to discover it in production if the failure mode isn't an infinite loop eating up CPU, but just an unhandled exception.
Pull Request Test Coverage Report for Build 4753859523
💛 - Coveralls |
I wonder if we should do a similar thing in It's also possible we could make |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@jonasfj This neverMatch is a list, I forgot the reason why I simplified it as a single value in this package. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love it!
@chenzhiguang, btw, I'm curious, why do It seems like:
Is there some logic to why |
You're right. |
@chenzhiguang I think that would be worth while. Or you just remove I would also make |
We throw an
AssertionError
ifBlockSyntax.parseLines
enters an infinite loop. This should have no effect, if there are no bugs. But if there is a bug, it's easier to discover it in production if the failure mode isn't an infinite loop eating up CPU, but just an unhandled exception.Context: We hit #531 in production, which caused an infinite loop. It would be much easier to detect what went wrong in cases such as this, if it just threw an error. That will have a stack trace :D
I also think it's hard to promise that this won't happen again, it looks as though all of these
BlockSyntax
objects are very interwoven, and their behavior might even be affected by the order in which they are given. And users can make subset of them, if they want to, possibly even subclass and customize syntaxes to make their own. All of which makes it a bit hard to promise there won't be any infinite loops or other bugs.I'm not sure how well customing a
BlockSyntax
subclass works, maybe if you mostly customize the output it'll mostly work -- I can definitely see cases where the result is hard to predict, and where any changes inpackage:markdown
is a breaking change 🤣