Lies we tell ourselves to keep using Golang

Re:Lies we tell ourselves to keep using Golang by j3s on Friday April 29, 2022 @05:56PM (#31211027)

consider this example - one using dynamic code with exception-based handling (ruby), and one using golang's more explicit error handling:

ruby:

  begin
    res = Net::HTTP.post_form(APIURL, ...)
    puts res.body
  rescue e => e
    # do error handling
  end

go:

  response, err := http.PostForm(APIURL, url.Values{...})
  if err != nil {
    # handle PostForm error
  }
  
  defer response.Body.Close()
  body, err := ioutil.ReadAll(response.Body)
  
  if err != nil {
    # handle ReadAll error
  }
  
  fmt.Printf("%s\n", string(body))

Now, for which errors do you handle? In golang, you can see clearly where errors may occur. In Ruby, it's unclear whether HTTP.post_form is even capable of throwing errors, much less what they are. For the record, here are a few of the many types of errors that can be thrown by the ruby code. Here are a few:

  Timeout::Error, Errno::EINVAL, Errno::ECONNRESET, EOFError, Net::HTTPBadResponse, Net::HTTPHeaderSyntaxError, Net::ProtocolError, ...

there's no way to tell _where_ the error will even come from - you might get a Net:: error, you might get a Timeout:: error, hell you could even get an Errno::! What most programmers wind up doing is handling no errors at all until they occur in runtime - or wrapping every single "suspicious" statement in a catch-all begin/rescue block, even when it's not needed.

In golang, each function capable of returning an error simply returns it, and you must handle it at that point in time. It is very straightforward. In my experience, it results in much more reliable code. In Ruby, you have no idea what's coming. Do you see what I mean?

[ Parent | on HN ]

Re:Lies we tell ourselves to keep using Golang by weatherlite on Sunday May 08, 2022 @08:55AM (#31303590)

> there's no way to tell _where_ the error will even come from - you might get a Net:: error, you might get a Timeout:: error, hell you could even get an Errno::! What most programmers wind up doing is handling no errors at all until they occur in runtime - or wrapping every single "suspicious" statement in a catch-all begin/rescue block, even when it's not needed.

Been programming Ruby for 8 years and have never seen anyone do that, so no... If that block of code can really throw so many different types of exceptions (usually - it can't) you can always catch StandardError.

[ Parent | on HN ]

Re:Lies we tell ourselves to keep using Golang by kaba0 on Friday April 29, 2022 @06:14PM (#31211193)

I’m not familiar with Ruby, but in java you can just specify the try-catch block’s scope as explicitly as you want.

``` try { var response = http.postForm(APIURL,) } catch (Exception e) { # handle PostForm error }

try { var body = ioutil.ReadAll(response.Body) } catch(SomeSpecificExceptionType e) { # handle specific exception differently } catch(Exception e) { # run for every other kind of error }

If a given method is defined as `void postForm(…) throws IOException` you have to handle the exception at the call site, or mark the containing call itself with a similar throws clause.

I really don’t see anything not handled by these. Also, the defer part can be done by a try-with-resources construct that will clause the resource in every case, whether exited without exception or with one.

[ Parent | on HN ]