errors joined from param parser: strings.Join(p.errors, "\n"

Error message

errors joined from param parser: strings.Join(p.errors, "\n")

What it means

This error is produced by the ParamParser in the route macro/path-template interpreter. It aggregates all individual parameter-validation failures collected while parsing a path parameter (e.g. an 'alphabetical' or 'int' macro failing) into a single error, one message per line, joined with '\n'. It means one or more path parameter values in an incoming request did not satisfy the declared parameter type in the route's path template.

Source

Thrown at macro/interpreter/parser/parser.go:105

func (p *ParamParser) Reset(src string) {
	p.src = src
	p.errors = []string{}
}

func (p *ParamParser) appendErr(format string, a ...any) {
	p.errors = append(p.errors, fmt.Sprintf(format, a...))
}

const (
	// DefaultParamErrorCode is the default http error code, 404 not found,
	// per-parameter. An error code can be set via
	// the "else" keyword inside a route's path.
	DefaultParamErrorCode = 404
)

func (p ParamParser) Error() error {
	if len(p.errors) > 0 {
		return errors.New(strings.Join(p.errors, "\n"))
	}
	return nil
}

// Parse parses the p.src based on the given param types and returns its param statement
// and an error on failure.
func (p *ParamParser) Parse(paramTypes []ast.ParamType) (*ast.ParamStatement, error) {
	l := lexer.New(p.src)

	stmt := &ast.ParamStatement{
		ErrorCode: DefaultParamErrorCode,
		Type:      ast.GetMasterParamType(paramTypes...),
		Src:       p.src,
	}

	lastParamFunc := ast.ParamFunc{}

	for {

View on GitHub (pinned to 7bedaf55a0)

Solutions

Check the multi-line message to see which parameter(s) failed and which macro was violated.
Fix the route path template to declare the correct parameter type for the data clients send.
Adjust client-side code to send values matching the macro (e.g. letters only for 'alphabetical').
If 404 DefaultParamErrorCode is undesirable, register a custom error handler / not-found handler on the router.

Example fix

// before
app.Get("/users/{name:alphabetical}", handler) // clients send /users/123

// after
app.Get("/users/{name:alphabetical}", handler)      // for names
app.Get("/users/{id:uint}", handler)                // for numeric IDs

Defensive patterns

Strategy: validation

Validate before calling

// client-side check before calling an alphabetical route
re := regexp.MustCompile(`^[a-zA-Z ]+$`)
if !re.MatchString(name) {
    name = strings.Join(strings.FieldsFunc(name, func(r rune) bool { return !unicode.IsLetter(r) && r != ' ' }), "")
}

Type guard

func isAlphabetical(s string) bool { return regexp.MustCompile(`^[a-zA-Z ]+$`).MatchString(s) }

Prevention

Mirror the server macro regex in client-side URL builders.
Prefer simple types (string, uint) unless strict validation is required.
Register a friendly 404 handler so users see a helpful message.

When it happens

Trigger: A request arrives whose path parameter fails macro evaluation, e.g. route registered as '/users/{name:alphabetical}' and a request hits '/users/john123'; the failing macro appends a formatted error to p.errors, and Error() joins them. Multiple failing params in one route produce multiple lines.

Common situations: Developers register typed path parameters (macro syntax) and end users request URLs with values that don't match; also happens after changing a macro type (e.g. int -> alphabetical) while old clients still send numeric values.

Related errors

AI-assisted analysis of kataras/iris@7bedaf55a0 (2026-08-30). Data as JSON: /api/errors/39d2d5360880aa59. Report an issue: GitHub.