Eliminate error

[ddkwork]

func ParseURL(rawURL string) (*url.URL, bool) {
        u, err := url.Parse(rawURL)
        if err != nil {
                return nil, false
        }
        if !IsURL(u) {
                return nil, false
        }
        NormalizeURL(u)
        return u, true
}

https://github.com/cogentcore/core/blob/main/coredom%2Fhandler.go#L281-L294

func Get(ctx *Context, url string) (*http.Response, error) {
        u, err := ParseRelativeURL(url, ctx.PageURL)
        if err != nil {
                return nil, err
        }
        resp, err := http.Get(u.String())
        if err != nil {
                return nil, err
        }
        if resp.StatusCode != http.StatusOK {
                resp.Body.Close()
                return resp, fmt.Errorf("got error status %q (code %d)", resp.Status, resp.StatusCode)
        }
        return resp, nil
}

[ddkwork]

I remember one time pr you disagreed with this way of writing, but looking at the official standard library of the go language, it does the same thing, and on another note, I don't know if go language developers in other countries have discussed the public opinion of the error checking syntax of the go language: "if err ! = nil {
return nil, err
}" and so on like a mountain of code disrupts the normal logic and breaks the world should be clean, in view of this, I would like to propose to encapsulate the following way to write:

func ParseURL(rawURL string) (url *url.URL, b bool) {
	u, err := url.Parse(rawURL)
	if !mylog.Error(err) {
		return
	}
	if !IsURL(u) {
		return
	}
	NormalizeURL(u)
	return u, true
}

func Get(ctx *Context, url string) (r *http.Response, err error) {//If a bool is returned here, the previous level of code will no longer show "if err ! = nil {"
	u, err := ParseRelativeURL(url, ctx.PageURL)
	if !mylog.Error(err) {
		return
	}
	resp, err := http.Get(u.String())
	if !mylog.Error(err) {
		return
	}
	if resp.StatusCode != http.StatusOK {
		resp.Body.Close()
		return resp, fmt.Errorf("got error status %q (code %d)", resp.Status, resp.StatusCode)
	}
	return resp, nil
}

[ddkwork]

// OpenImage sets the image to the image located at the given filename.
func (im *Image) OpenImage(filename Filename) error { //gti:add
	img, _, err := images.Open(string(filename))
	if err != nil {
		slog.Error("gi.Image.OpenImage: could not open", "file", filename, "err", err) //gi.Image.OpenImage It's fetched uniformly by runtime.Caller(), and we can just wrap it uniformly once inside the "func Error(err any) bool {" function
		return err
	}
	im.Filename = filename
	im.SetImage(img)
	return nil
}

then:

// OpenImage sets the image to the image located at the given filename.
func (im *Image) OpenImage(filename Filename) bool { //gti:add
	img, _, err := images.Open(string(filename))
	if !mylog.Error(err) {
		return false
	}
	im.Filename = filename
	im.SetImage(img)
	return true
}

The go language standard library wraps the errors package to wrap the layers of error, real-world scenarios do not need to do that, we just need to print the line number, method name, and so on in each of the first occurrence of error location. This is clear at a glance, a short period of time can quickly troubleshooting. Given this, error no longer needs to be returned, but all error types should be changed to bool, so that the mountain of "if err ! = nil {" disappears and becomes "if (xxx) {"

[ddkwork]

[kkoreilly]

I also find the Go system of error handling painful at times, but it is the Go standard that everyone else follows, and we have no choice but to follow it. There are many cases in which you need to do something with the error object, and we cannot simply assume that everyone wants to have it logged and do nothing else with it.

[ddkwork]

I also find the Go system of error handling painful at times, but it is the Go standard that everyone else follows, and we have no choice but to follow it. There are many cases in which you need to do something with the error object, and we cannot simply assume that everyone wants to have it logged and do nothing else with it.

Maybe my description is not accurate enough, please see the official way of go, I didn't ignore the error

https://github.com/golang/go/blob/master/src%2Fgo%2Fast%2Fprint.go#L43-L69

[ddkwork]

The err variable is defined at the place it returns, the default is nil, and it will always be nil if you don't assign a new value to it anywhere in the function, so it's the same everywhere else, we just need to give him a new error value where the error occurred. In this way the n+nil disappears, and for me the readability of 1-300 go files is greatly improved

[ddkwork]

https://go.dev/doc/effective_go#named-results

[kkoreilly]

I am strongly opposed to named returns if they are not needed, as they make it incredibly unclear what values are being returned. Unless there are multiple return values with unclear meanings, we will not use named returns. The Go convention is to not use named returns for simple error return values.

[ddkwork]

ok