As reported in hashicorp/terraform#10854, when HIL implicitly converts from string to one of the other types it calls into one of the conversion functions in the Go standard library, and if the conversion fails HIL just passes through verbatim the Go-oriented error message. For example:
* __builtin_StringToBool: strconv.ParseBool: parsing "sg-0a784a77": invalid syntax in:
${var.sg_id ? var.sg_id : aws_security_group.main.id}
Several things wrong with this error message:
- It exposes the implementation detail that conversion is implemented via builtin functions (
__builtin_StringToBool)
- It mentions
strconv.ParseBool, which is a Go library function and not something anyone using HIL is expected to be familiar with.
- The phrasing is confusing and can be misunderstood that the syntax error is in the interpolation expression
${var.sg_id ? var.sg_id : aws_security_group.main.id} rather than in the value "sg-0a784a77".
- The line and column number of the errant expression are not included. (Currently including this would not actually help much in Terraform since it doesn't retain HCL position context when parsing HIL, but I hope to fix that later...)
Proposed better error message (with similar variants for other types converting to string):
* can't convert string "sg-0a784a77" to bool at foo.tf:12:2; must be either "true" or "false"
This addresses the three things I think should be included in all good error messages: "What's the problem (in user-facing terminology)?" "Where is the problem?" "How might the problem be corrected?"
As reported in hashicorp/terraform#10854, when HIL implicitly converts from string to one of the other types it calls into one of the conversion functions in the Go standard library, and if the conversion fails HIL just passes through verbatim the Go-oriented error message. For example:
Several things wrong with this error message:
__builtin_StringToBool)strconv.ParseBool, which is a Go library function and not something anyone using HIL is expected to be familiar with.${var.sg_id ? var.sg_id : aws_security_group.main.id}rather than in the value"sg-0a784a77".Proposed better error message (with similar variants for other types converting to string):
This addresses the three things I think should be included in all good error messages: "What's the problem (in user-facing terminology)?" "Where is the problem?" "How might the problem be corrected?"