assert: arguments: Error(%d) failed because object wasn't co

Error message

assert: arguments: Error(%d) failed because object wasn't correct type: %v

What it means

Panicked by Arguments.Error(index) (mock/mock.go:1124) when args.Get(index) is non-nil and does not type-assert to the builtin error interface. Note: nil is handled (returns nil error at mock/mock.go:1128-1130); the panic only fires for present-but-wrong types. Message prints the offending value.

Source

Thrown at mock/mock.go:1132

	var s int
	var ok bool
	if s, ok = args.Get(index).(int); !ok {
		panic(fmt.Sprintf("assert: arguments: Int(%d) failed because object wasn't correct type: %v", index, args.Get(index)))
	}
	return s
}

// Error gets the argument at the specified index. Panics if there is no argument, or
// if the argument is of the wrong type.
func (args Arguments) Error(index int) error {
	obj := args.Get(index)
	var s error
	var ok bool
	if obj == nil {
		return nil
	}
	if s, ok = obj.(error); !ok {
		panic(fmt.Sprintf("assert: arguments: Error(%d) failed because object wasn't correct type: %v", index, obj))
	}
	return s
}

// Bool gets the argument at the specified index. Panics if there is no argument, or
// if the argument is of the wrong type.
func (args Arguments) Bool(index int) bool {
	var s bool
	var ok bool
	if s, ok = args.Get(index).(bool); !ok {
		panic(fmt.Sprintf("assert: arguments: Bool(%d) failed because object wasn't correct type: %v", index, args.Get(index)))
	}
	return s
}

// safeTypeName returns the reflect.Type's name without causing a panic.
// If the provided reflect.Type is nil, it returns the placeholder string "<nil>"
func safeTypeName(t reflect.Type) string {

View on GitHub (pinned to 001eb7946b)

Solutions

Verify the argument actually implements error before calling args.Error, using a type switch.
Fix the index so it points at the real error-typed parameter.
If the value is a wrapper, expose it via an Err() method or assert on the concrete type then extract.

Example fix

// before
err := args.Error(0) // arg is a custom Result
// after
switch v := args.Get(0).(type) {
case error: err = v
case Result: err = v.Err()
}

Defensive patterns

Strategy: type-guard

Validate before calling

func argIsError(args mock.Arguments, i int) bool {
    if i >= len(args) { return true } // nil is allowed
    if v := args.Get(i); v != nil {
        _, ok := v.(error); return ok
    }
    return true
}
// before args.Error(i): if !argIsError(args, i) { t.Fatal("arg not error") }

Type guard

func argIsError(args mock.Arguments, i int) bool {
    if i >= len(args) { return true }
    if v := args.Get(i); v != nil {
        _, ok := v.(error); return ok
    }
    return true
}

Try / catch

// Use a type switch to safely extract:
switch v := args.Get(i).(type) {
case nil: err = nil
case error: err = v
default: t.Fatalf("unexpected type %T", v)
}

Prevention

Use type switches for error extraction to surface the real type on mismatch.
Verify argument indices after method signature changes.
Wrap custom result types so they expose Err() error.

When it happens

Trigger: Calling args.Error(0) when the argument is a non-error value (string, struct, *http.Request) or a custom error type that doesn't satisfy the error interface. Also when the method returns/accepts a wrapped error type that was passed as a concrete struct.

Common situations: Method signature changed so a positional argument is no longer an error; using a custom result type that embeds but isn't exposed as error; asserting on the wrong index.

Related errors

AI-assisted analysis of stretchr/testify@001eb7946b (2026-08-04). Data as JSON: /data/errors/40c6e505bf3e959a.json. Report an issue: GitHub.