Why Does `fmt.Println` Output 'bad error' Instead of '5' When an Interface Variable Implements the `error` Interface?

Golang Interfaces: Understanding the Unexpected "bad error" Output

In Go, interfaces provide a mechanism for defining and implementing common methods across different types. However, an intriguing situation arises when an interface type defines an Error() method and is assigned to an interface variable.

Consider the following code snippet:

type T int

func (t T) Error() string {
    return "bad error"
}

func main() {
    var v interface{} = T(5)
    fmt.Println(v) // Output: "bad error", instead of "5"
}

Surprisingly, the output of the above code is "bad error" instead of the expected value of 5. This occurs because fmt.Println() implicitly invokes the Error() method if the operand implements the error interface.

As stated in the fmt package documentation:

If an operand implements the error interface, the Error method will be invoked to convert the object to a string, which will then be formatted as required by the verb (if any).

The error interface defines a single method, Error(), which returns a string describing the error. When v is printed, it's processed according to the %v format specifier, which automatically calls the Error() method if it's present.

To obtain the intended output, one can use the Printf() function with an appropriate format specifier, such as %d for integers:

fmt.Printf("%d", v) // Output: "5"

In summary, when assigning types with defined Error() methods to interface variables, one must be aware of the potential for unexpected "bad error" outputs when employing the Printf() family of functions with implicit argument formatting.

The above is the detailed content of Why Does `fmt.Println` Output 'bad error' Instead of '5' When an Interface Variable Implements the `error` Interface?. For more information, please follow other related articles on the PHP Chinese website!