What must the target argument to errors.As be, and what happens if it is not a pointer?

## The function ```go func As(err error, target any) bool ``` `errors.As` answers the question "is there an error of *this concrete type* anywhere in this error, and if so, hand it to me". It is the typed counterpart to identity matching: instead of asking whether the error *is* one particular value, you ask whether some error in the chain has a type you can read fields off. ## What it does It walks the error, then the error that one wraps, and so on. At each step it asks whether the error's concrete type is **assignable** to the type that `target` points at. On the first match it performs the assignment and returns `true`. If it runs off the end of the chain it returns `false` and leaves the target untouched. That assignment is the reason for the whole target convention. `errors.As` has no other way to hand you a value of a type it does not know at compile time, so you give it the address of a variable of the type you want and it fills it in — an out-parameter, the same shape as `encoding/json`'s `Unmarshal`. ```go var fe *FieldError if errors.As(err, &fe) { // fe now points at the FieldError found in the chain return badRequest(fe.Field) } ``` Note the double indirection: the value you want is a `*FieldError`, so the variable is a `*FieldError` and the target is `&fe`, a `**FieldError`. Getting one level wrong is the single most common mistake with this function. ## The rules on target The target must be: * **a pointer**, and * **not nil**, and * pointing at either a **type that implements `error`**, or at **any interface type**. Violate any of those and `errors.As` panics. The panics are distinct — a nil target, a non-pointer target, and a pointer to something that is neither an interface nor an error — but they all mean the same thing: the call as written can never work for any input. ## Why a panic rather than false Returning `false` would be worse. `false` is a legitimate answer that the calling code will act on, so a permanently-wrong target would silently disable a branch: retries that never happen, an HTTP 500 where a 422 belonged, a validation failure that never gets reported per-field. A panic makes the mistake impossible to miss the first time the code path runs. It is treated as a bug in the program, not as a runtime condition. ## The trap: it only fires on the error path That design has one sharp edge. `errors.As` is called precisely when something has gone wrong, so a bad target sits dormant through every test that exercises the success path. A package generated from a schema is a good example: the generator emits both the error type and the handling code, and if the emitted call passes a value rather than a pointer, the whole package tests green and then panics in production the first time a document fails validation — turning a routine 422 into a crashed request, or a dead process if nothing recovers. Two defences: * `go vet`'s **`errorsas`** analyzer reports a call to `errors.As` whose second argument is not a pointer to a type implementing `error`. It is part of the vet subset that `go test` runs by default, so a plain `go test ./...` over the generated package catches it without extra wiring. * A test that actually drives one failing input through the public function, so the error path is executed at least once. ## Interface targets A pointer to an *interface* type is allowed and is genuinely useful when you care about a capability rather than a named type. If a third-party SDK's error types are not exported, but they all carry a method you can name, you can match on it: ```go var coded interface{ StatusCode() int } if errors.As(err, &coded) { log.Printf("upstream status %d", coded.StatusCode()) } ``` Here `*target` is an interface type, so the rule about implementing `error` does not apply, and the first error in the chain that has the method wins. ## Several matches If more than one error in the chain matches, you get the **first one found** in traversal order — the outermost — and the search stops there. If you need a specific one of several, match on a narrower type. ## Versions `errors.As` arrived in Go 1.13 together with `errors.Is`, `errors.Unwrap` and the `%w` verb. Go 1.20 extended the traversal to error trees. Go 1.26 added `errors.AsType`, a generic alternative that returns the extracted value and a bool instead of taking a pointer target, which removes this whole class of target mistakes at the cost of requiring a newer toolchain.