Middle · Go foundations
Typed nil and method sets
Why can err != nil even though its pointer is nil?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
An interface value carries a dynamic type and value. A nil *Problem stored in error still supplies a dynamic type; only an interface with no dynamic type or value compares equal to nil.
T and *T have different method sets. A value with only pointer-receiver methods does not satisfy the corresponding interface even though an addressable variable may use an implicit address in a method call.
Return literal nil for the successful error result. Keep interfaces near their consumers and small enough to describe the needed behavior. Avoid interface{} just to make every implementation fit.
Common trap
A successful method call on an addressable value does not prove that the value type satisfies an interface.
Try it
Implement an error with a pointer receiver and return a typed nil; then fix the success path.
Worked solution
Returning (*Problem)(nil) as error creates a non-nil interface. A branch returning nil keeps the error interface nil. Add a test on the public error result, not on the internal pointer.
Change the constraint
When is a nil receiver method useful, and why must it check the receiver before dereferencing it?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.