Why does Go return a pointer to an error wrapper but declare it with 'error' instead of '*error'

WBOY
Release: 2024-02-09 22:40:10
forward
549 people have browsed it

为什么 Go 返回一个指向错误包装器的指针,但用“error”而不是“*error”声明它

Why does Go return a pointer to an error wrapper but declare it with "error" instead of "error"? This is a common problem that many Go language developers encounter. Simply put, the way Go returns errors is to make it easier to use and handle errors. In Go, an error is an interface type that has an Error() method that returns an error message. Therefore, when a function returns an error, it actually returns a pointer to a structure that implements the Error() method. This design makes error handling more concise and flexible, reducing code redundancy and complexity. So while returning a pointer may seem strange, it's actually intended to provide better error handling.

Question content

I am learning Go language from Java background.

type MyError struct {
    message string
    Offset  int
}

func (Me *MyError) Error() string {
    return Me.message
}

func myFunction() (int, error) {      <-- Why the return type is "error" rather than "*error"
    return 0, &MyError{"my error message", 0} <-- The error is returned as a pointer.
}

func main() {
    var _, err = myFunction()
    if e, ok := err.(*MyError); ok {.  <-- Why I can assert err which is a type of "error" into a pointer
        fmt.Printf("Error is %s: %d\n", e.message, e.Offset)
    }
}
Copy after login

In the above code, I don't understand why the error type of myFunction is "error" instead of "*error"? I am clearly returning a pointer to the MyError structure in the line below.

I also understand why I can assert the error in the main function back to the pointer.

Solution

To understand traditional error handling in Go, you should first understand how interfaces in the language work. There are two things to remember when talking about Go interfaces:

  1. An interface in Go defines a set of methods (starting from Go1.18 is also a set of types). Behind the scenes, a Go interface contains two elements, type T and value V. V Always is a concrete type, such as int, struct, or a pointer, not the interface itself.

  2. There is no implements keyword in Go. Go types satisfy this interface by implementing its methods. This is called implicit implementation.

Error handling

Go defines a built-in error type, which is just an interface:

type error interface {
    Error() string
}
Copy after login

In fact, there's nothing special about it, except that it's a global predeclared type. This type is typically used for error handling.

Take your example:

func myFunction() (int, error) {
    return 0, &MyError{"my error message", 0}
}

func main() {
    var _, err = myFunction()
    if e, ok := err.(*MyError); ok {
        fmt.Printf("Error is %s: %d\n", e.message, e.Offset)
    }
}
Copy after login

The relationship between the pointer to MyError and the error interface happens behind the scenes, you don't need to explicitly return *error from MyError value reference error (In fact, you almost never need a pointer to an interface ).

After returning myFunction, the error value will hold the following tuple (V=&MyError{message: "my error message", Offset: 0}, T=* MyError), where V is its value hold and T is the type of value V.

Because Go allows you to type assertions on interface values. Basically, the Go operation you're asking about e, ok := err.(*MyError) is: the err value (which type is the error interface) Does type *MyError have as its underlying T? If so, ok will be true, and e will receive its underlying V value &MyError{message: "I The error message is ", Offset: 0}.

Note: Please treat nil error values ​​with caution, as they may not always behave as expected due to subtle differences in the interface.

The above is the detailed content of Why does Go return a pointer to an error wrapper but declare it with 'error' instead of '*error'. For more information, please follow other related articles on the PHP Chinese website!

source:stackoverflow.com
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template
About us Disclaimer Sitemap
php.cn:Public welfare online PHP training,Help PHP learners grow quickly!