Improve YamlError ADT
#271
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Also having it on the 'ConstructError' would help. When you construct data types from the YAML-Nodes and fail, you want to know where you failed. |
By providing the `ParseError`, `ConstructError` and `ScannerError` the original information that caused the error, an end user can use it for better diagnostics down the line.
|
I added the same treatment to |
|
better question here is: are these all of the changes that users could possibly have for errors? it would be probably good to do this change once since it breaks b/compat |
|
@tgodzik looks fine :) |
It would be nice, indeed, Do you see any other things were we should/could add more information? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I am opening this pull request to discuss the idea of improving (and "opening") the
YamlErrorADT.Currently, only "ascii" messages are provided to the end users. So after calling a method like
asNodeon aString, all underlying information (position of the error, token responsible, expected token kind) are no more available.The
ParseErroris the most obvious enhancement, but the same philosophy can probably be applied to others, like theComposeError, for example.This will be a (slight) breaking change (in the case people were destructuring the
ParseErrorcase class in a match statement, for example) but since it will only lead to compile-time error, I don't think it's a big deal.I'm adding a regression test to verify that the actual error message did not change (and will not, at least not unwillingly).