Why do Terraform validation conditions so often wrap an expression in `can()`, and what goes wrong if the condition expression itself raises an error?

## The shape a condition must have The `condition` argument of a `validation` block — and of a `precondition` or `postcondition` — must produce a boolean. Terraform then takes one of two paths: `true` and it continues, `false` and it reports your `error_message`. There is a third outcome nobody designs for: the expression *errors*. Evaluation of the condition itself blows up. Terraform still fails the run, but the diagnostic the operator reads comes from the function that exploded, not from you. ## Which functions error instead of returning false This catches people because the failure mode is invisible in the happy path. Several HCL functions treat malformed input as an error, on the reasoning that in most contexts a silently wrong value would be worse: - `regex(pattern, string)` — raises an error when the pattern does not match. It is a *extract the match* function, not a *does it match* function. - `cidrsubnet`, `cidrhost`, `cidrnetmask` — raise on a string that is not a valid CIDR prefix. - `tonumber` — raises on a string that does not parse as a number. - Indexing a list past its end, or looking up a map key that is not there. Write `condition = regex("^[a-z-]+$", var.name) != ""` and the valid case works fine while the invalid case — the one the rule exists for — produces `Call to function "regex" failed: pattern did not match any part of the given string`. Technically the run stopped, so nothing was built. Practically you have replaced a message explaining the naming standard with an error about pattern matching, and the person reading it now has to open your module to find out what it wanted. ## What can() does `can(expression)` evaluates its argument and returns `true` if evaluation succeeded and `false` if it raised an error. That converts "this function refused to process the value" into "the value is not acceptable", which is precisely the boolean a condition needs. ```hcl variable "bucket_name" { type = string validation { condition = can(regex("^[a-z0-9][a-z0-9.-]{1,61}[a-z0-9]$", var.bucket_name)) error_message = "The bucket_name must be 3-63 lowercase letters, digits, dots or hyphens, starting and ending with a letter or digit." } } ``` Now a malformed name gets that sentence. `can(cidrnetmask(var.vpc_cidr))` is the same trick for "is this a real CIDR block", and `can(tonumber(var.port))` for "is this string numeric". Two cautions. First, `can` is deliberately narrow: it is meant for wrapping one expression whose failure you understand, not for swallowing whatever a large expression might do. A `can()` around a compound expression turns *every* mistake in it, including your own typo in a variable name, into a plain `false` and therefore into a misleading error message. Second, it catches errors raised while evaluating the expression — it is not a general-purpose try/catch for the language, and it does not make an otherwise invalid configuration valid. ## try() and the difference `try(expr1, expr2, ...)` returns the first argument that evaluates without error. It is about producing a **value** with a fallback, not about producing a boolean: ```hcl locals { port = try(tonumber(var.port), 8080) } ``` In a validation context you occasionally want `try` to normalise before comparing, but the direct rule-shaped tool is `can`. A quick way to keep them straight: `can` asks *did that work?*, `try` asks *what is the first thing that works?* ## The principle underneath A condition should never be able to fail — only to be false. Whenever a condition calls a function that can raise, you either wrap it in `can()` or you have written a rule that reports someone else's error message on exactly the input it was built to reject. That is the whole idea, and it generalises: the value of validation is not that the run stops, it is that the run stops *with an explanation*, and an unwrapped error-raising function throws that value away.