Live data from Hacker News

Weatherme CLI Tool

github.com

11–20 of 30 posts

Re: Weatherme CLI Tool

#12
I suppose this is as good a time as any to plug noaa, a CLI tool that can give you the current conditions and forecast, but also allows you to retrieve any product the US National Weather Service produces. It’s way geekier than the above, but perhaps more useful for some.

https://github.com/sramsay/nowa/

(I am also the author of wu, which was a popular cli tool for the Weather Underground API. I had to discontinue that when they closed free access to their API. That was written in Go; this one is written in C).

Re: Weatherme CLI Tool

#14
post #12

I suppose this is as good a time as any to plug noaa, a CLI tool that can give you the current conditions and forecast, but also allows you to retrieve any product the US National Weather Service produces. It’s way geekier than the above, but perhaps more useful for some. https://github.com/sramsay/nowa/ (I am also the author of wu, which was a popular cli tool for the Weather Underground API. I had to discontinue th…

Thank you for wu and this too, Please enlighten me on why nowa is written in C, would you?

Re: Weatherme CLI Tool

#16

This cannot be the real secret api key? https://github.com/eoin-barr/weatherme/blob/master/cmd/root....

That function shows the state of error handling in Go.

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)
    }

Re: Weatherme CLI Tool

#17

Earlier quoted context omitted.

That function shows the state of error handling in Go.

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

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!

Re: Weatherme CLI Tool

#18

Earlier quoted context omitted.

That function shows the state of error handling in Go.

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

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...
Post reply on HN