[WirelessGigabit]

That function shows the state of error handling in Go.

[ilyt]

Uh, no, it's just bad code.

Don't get me wrong, error handling is verbose and annoying, but not even displaying actual error is just horrible coding practice.

should be at the very least

    err = json.Unmarshal(weatherBody, &WeatherRes)
    if err != nil {
        fmt.Printf("error decoding weather json: %s\n",err)
 return
    }

or just be function that returns that error or the weather

    err = json.Unmarshal(weatherBody, &WeatherRes)
    if err != nil {
 return fmt.Errorf("error decoding weather json: %s\n",err)
    }

[Alifatisk]

No I meant https://github.com/eoin-barr/weatherme/blob/master/cmd/root....

[alexeldeib]

wouldn't mind a question mark for checking nil err like result in rust..

[ilyt]

I'd even settle for

    return err if err != nil

everything better than three fucking lines every time something returns err.

Especially that some clown decided that apparently

    if err != nil { return err }

is too terse and go fmt just goes back to expanding it to 3 lines...

[datalopers]

What is an example of a better approach? Methods that throw exceptions?

[Gorath]

I just don’t understand why this is better than returning an error to caller? E.g have an err return type that could be nil. This type of practice just seems to ask for undefined behavior or debugging frustration. when you finally track down this log statement, we have multiple call sites to choose from to determine where this free form log string came from. Hopefully the same generic string was not used in a separate function!