hcl: More helpful error messages in Index and GetAttr #474
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.
When we first implemented these helpers we tried to anticipate a few situations that seemed likely to come up and implement specialized error messages for them, but in the intervening years we've seen a number of other situations crop up with some regularity.
Given that, I've added a few more specialized error message cases to both of these functions, so we'll return the most generic error messages in fewer situations.
Because
hcl.Index
andhcl.GetAttr
are quite general functions used for lots of different application-specific purposes alongside their part in the implementation of the index and attribute access operators, I've intentionally kept these messages quite vague in the suggestions they make, which does mean that unfortunately users will probably need to do some further research to find a suitable resolution to these messages. Hopefully the extra context at least gives the user a better hook for that further research.Later we could consider putting some pre-checks in the actual operator implementations that would catch some of these prior to calling the generic functions and return a more directly-prescriptive error message which assumes we're in an expression evaluation context, but I'd like to see how these new messages are received in practice first, to see if that additional complexity would be warranted.