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

Error handling could be _further_ improved #108

Open
finnbar opened this issue Jan 6, 2022 · 1 comment
Open

Error handling could be _further_ improved #108

finnbar opened this issue Jan 6, 2022 · 1 comment
Labels
discussion needed for when an implementation is uncertain IMPORTANT These are serious things to focus on major

Comments

@finnbar
Copy link
Collaborator

finnbar commented Jan 6, 2022

WithError is solid, but sometimes branches are missed and lead to very ugly errors. Furthermore, due to the intricacies of Maybe, we can get some very weird errors - which of the parts of the parser should error in Maybe a -> Maybe b -> c -> ... if neither of the Maybes are present?

This needs some discussion, but thoughts that came up were:

  • Default errors for parts of the SmartParser - i.e. a Text should default error with error: expecting Text that should be overridden.
  • "maybe you meant one of:" seems to be... not very clear most of the time.
  • Try to avoid "unknown error" as much as possible - maybe plugins should have a default "error in x plugin"?

I think the system of using parser names is probably unreliable (we name parsers with their error messages using <?> and slightly change the reporting system to make it clearer to users) - maybe there's other stuff in megaparsec that can help with error parsing? This needs some serious investigation, regardless.

@finnbar finnbar added major discussion needed for when an implementation is uncertain labels Jan 6, 2022
@finnbar
Copy link
Collaborator Author

finnbar commented Feb 5, 2022

Okay, we have a slight plan! Soon to be merged (or already merged depending on when you're reading this, it's in dice stats) is the <??> operator, which uses MonadFail's fail to create an error. That error looks good, and isn't hacky! So we should use that.

Needs to make sure that the most specific error is reported. I think the first error suffices here, but this will need research.

@finnbar finnbar added the IMPORTANT These are serious things to focus on label May 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion needed for when an implementation is uncertain IMPORTANT These are serious things to focus on major
Projects
None yet
Development

No branches or pull requests

1 participant