Skip to content
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

Better Error handling #19

Open
QuickWrite opened this issue Mar 10, 2023 · 3 comments
Open

Better Error handling #19

QuickWrite opened this issue Mar 10, 2023 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@QuickWrite
Copy link
Owner

With the current implementation the parser is completely stopping when it finds an error. This can be quite cumbersome as sometimes you have multiple errors in the same file which means that you need to parse it, find the errors and parse it again (and do the same thing multiple times).

It would be a lot easier if the error handling would work so that all of the errors are being reported.

The problem with this is of course that when an error is being detected the parser must be able to "recover" from this error so that it does not spit out thousands of errors as it still tries to parser the file in a specific way.
Maybe it would be sensible to create a custom error handler for a parser and when it detects an error it is correctly handling the situation.

@QuickWrite QuickWrite self-assigned this Mar 10, 2023
@QuickWrite QuickWrite added the enhancement New feature or request label Mar 10, 2023
@QuickWrite
Copy link
Owner Author

Maybe it would be good if the result of the parser would also include a list of errors that were found at the parsing stage.

@QuickWrite
Copy link
Owner Author

The only problem is that the parser is modular and with that the error recovery can be tricky as it cannot just parse after that. There must be a system that skips the next characters when it found out that an error happened.

@QuickWrite
Copy link
Owner Author

But the messages that contained some parsing errors shouldn't be in the result and only in the errors list as it isn't clear if that message can be read or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant