1

Hello everyone, I am fried fish.

Error handling has always been a contentious part of Go, with people contributing all sorts of ideas to this type of proposal. During the May Day holiday, I also found an interesting technical proposal, that is: the left-hand function; and the new idea of Go+.

Today, Fried Fish will take you to see it together.

New Go Proposal: Left Function

Under the existing error handling mechanism of Go1, we generally need to write a lot of logic if err != nil to handle errors.

Someone joked that 50 out of 100 lines were the following code:

 func main() {
 x, err := foo()
 if err != nil {
   // handle error
 }
 y, err := foo()
 if err != nil {
   // handle error
 }
 z, err := foo()
 if err != nil {
   // handle error
 }
 s, err := foo()
 if err != nil {
   // handle error
 }
}

So many friends in the community came up with the idea of the left function .

It is hoped that this will solve the problem of error handling, reduce the extra 3 lines of code written each time, and achieve a consistent error handling method.

The following proposals are involved:

The new code in the proposal is as follows:

 fmt.Errof("%v, %w", a, err) := simple()

Simplified writing:

 errorHandle(err) = io.Copy(w, r)

The new processing idea is to add a layer (universal software architecture processing method), and use the left function to handle all errors.

Go+: bad expression

A member related to Go: Go+, also made its own " ErrWrap expressions " error handling solution, which was discussed by some people in the previous proposal, so everyone can evaluate it together.

Introduction to expressions

The core idea is to add an expression syntax mechanism to error handling. as follows:

 expr! // panic if err
expr? // return if err
expr?:defval // use defval if err

Below we will introduce them one by one.

The expression expr! checks if valN is zero. If not, it will panic. Corresponding Go code:

 val1, val2, ..., valN1, valN := expr
if valN != nil {
    panic(errors.NewFrame(valN, ...))
}
val1, val2, ..., valN1 // value of `expr!`

The expression expr? checks if valN is nil, if not, it returns an error. Corresponding Go code:

 val1, val2, ..., valN1, valN := expr
if valN != nil {
    _ret_err = errors.NewFrame(valN, ...)
    return
}
val1, val2, ..., valN1 // value of `expr?`

The expression expr?:defval checks if valN is nil. If not, it uses defval as the value of expr. Corresponding Go code:

 val1, val2 := expr
if val2 != nil {
    val1 = defval
}
val1 // value of `expr?:defval`

demo code

Specific sample code:

 import (
    "strconv"
)

func add(x, y string) (int, error) {
    return strconv.Atoi(x)? + strconv.Atoi(y)?, nil
}

func addSafe(x, y string) int {
    return strconv.Atoi(x)?:0 + strconv.Atoi(y)?:0
}

println(`add("100", "23"):`, add("100", "23")!)

sum, err := add("10", "abc")
println(`add("10", "abc"):`, sum, err)

println(`addSafe("10", "abc"):`, addSafe("10", "abc"))

Output result:

 add("100", "23"): 123
add("10", "abc"): 0 strconv.Atoi: parsing "abc": invalid syntax

===> errors stack:
main.add("10", "abc")
    /Users/xsw/goplus/tutorial/15-ErrWrap/err_wrap.gop:6 strconv.Atoi(y)?

addSafe("10", "abc"): 10

In addition to the optimization of the mechanism for error handling based on expressions, information tracking of the error stack is also added.

Summarize

In today's article, we discussed the proposal for the error handling mechanism that Go is currently "burning". There are try-catch, panic replacement, etc., and there are new ideas such as left-hand functions and expressions.

What do you think about these error handling methods, can you solve them?

Welcome to leave a message and exchange in the comment area.

The article is updated continuously, you can read it by searching on WeChat [Brain fried fish]. This article has been included in GitHub github.com/eddycjy/blog . If you are learning Go language, you can see the Go learning map and route . Welcome to Star to urge you to update.

read more

Go Book Series


煎鱼
8.4k 声望12.8k 粉丝