In Terraform, what class of errors does the try() function actually catch, and when is lookup() or coalesce() the better choice?

## What try actually does `try` takes one or more expressions and returns the result of the first one that succeeds: ```hcl try(var.config.timeout, 30) try(local.parsed.settings["region"], var.default_region, "us-east-1") ``` The documented restriction is that it can only catch **dynamic errors relating to data structure** — that is: - accessing an attribute that the value does not have; - indexing a list, map or tuple with a key or position that is not there; - a type conversion that cannot be performed. Everything else is still a hard failure. A function called with the wrong number of arguments, a provider rejecting an argument, a reference to a name that does not exist in the configuration at all — these are static or provider-level problems that `try` cannot and does not intercept. ## Why "use it sparingly" is real advice, not boilerplate The danger is scope. Compare: ```hcl try(var.cfg.database.port, 5432) # narrow try(jsondecode(file(var.path)).db.port, 5432) # wide ``` The second swallows a missing file, malformed JSON, a renamed key, and a typo in `db` — all as "use 5432". You deploy against the wrong port and Terraform reports success. When the fallback path is a legitimate outcome, keep the `try` around the smallest traversal that can legitimately be absent. When absence means the input is wrong, do not use `try` at all: let it fail, or reject it up front so the error names the real problem. ## The neighbouring functions, and when each fits - **`lookup(map, key, default)`** — the value may be a *missing key in a map*. With a default supplied, the missing key returns the default; without one, a missing key is an error. Where the key is a literal you know at write time, index syntax `local.m["key"]` is clearer and the documentation prefers it; `lookup`'s reason to exist is the default and the dynamically computed key. - **`coalesce(a, b, ...)`** — the value *exists* but may be null or an empty string. Coalesce returns the first argument that is neither. That "empty string counts as absent" rule is exactly what you want for user-supplied strings and exactly what surprises people who expected only null-checking. `coalescelist` is the list-shaped sibling. - **`can(expr)`** — returns `true` or `false` rather than a value, catching the same narrow class of errors as `try`. It answers "would this expression work?" and is the right tool when you want a boolean for a conditional rather than a fallback value. - **`one(list)`** — returns the single element of a one-element list, `null` for an empty list, and errors on more. Cleaner than `try(list[0], null)` when "zero or one" is the real contract. ## Prefer fixing the type over patching the expression A lot of `try` in real repositories exists because the input variable's type is loose — `any`, or an object whose optional fields were never declared. Terraform's `optional()` modifier inside an object type constraint lets you declare a field as optional and give it a default, so the value is already normalised before any expression touches it: ```hcl variable "cfg" { type = object({ name = string timeout = optional(number, 30) }) } ``` Every downstream `try(var.cfg.timeout, 30)` disappears. When you own the interface, this is strictly better: the default is documented in one place, and a genuinely wrong input still produces a real error instead of quietly taking the fallback. ## Null, empty and unknown are three different things A senior answer distinguishes them: - **null** means "argument omitted" — assigning null to a resource argument is the same as not setting it, which lets the provider apply its own default. - **empty** (`""`, `[]`, `{}`) is a real value that is present and blank. `coalesce` treats an empty string as absent; a plain `!= null` check does not. - **unknown** — `(known after apply)` — is a value that will exist but is not computed yet at plan time. `try` and `can` do not resolve unknowns: an unknown propagates through them, and a conditional whose predicate is unknown makes the whole result unknown. This is why a config full of defensive `try` can still produce a plan that is mostly `(known after apply)`. ## What good looks like Narrow scope, the right function for the actual failure mode, and a preference for making bad input impossible over making it survivable. If a reviewer cannot tell from the expression *which* absence you were tolerating, the `try` is too wide.