Improve YamlError ADT
#271
Conversation
|
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? |
|
Is there a reason why you'd not put the failing Node instance to |
|
|
||
| final case class NoRegisteredTagDirective(handleKey: String, tokenTag: Token) extends ParseError { | ||
| def msg: String = s"There is no registered tag directive for handle $handleKey" | ||
| } | ||
| } | ||
|
|
||
| final case class ComposerError(msg: String) extends YamlError | ||
|
|
||
| final case class ModifyError(msg: String) extends YamlError |
There was a problem hiding this comment.
for future: ModifyError is shouldn't rather be part of YamlError hierarchy. cc: @lbialy
There was a problem hiding this comment.
Could you quickly enumerate what each of these error types is meant to represent and when can they occur?
|
(Apologies, I was on vacation and I missed the notif!) Do you mean something like here? I would love to, but I am not sure the information is available there. Or am I mistaken? |
|
More like https://github.com/VirtusLab/scala-yaml/pull/271/files#diff-32973d256749bcd5d6f523448e86986a9ce9483feb6047a712ae41b7e23d2670R22 where it can be |
|
Superseded by #309 |
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).