Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

hah. It's #1 "err", #2 "if", #3 "return", #4 "nil". :)

That must be because a lot of function calls are followed by:

  if err != nil {
      return err
  }
https://stackoverflow.com/questions/18771569/avoid-checking-...

reply



sort by: page size:

Right, by typing a zillion if err != nil return err lines of code. In any sophisticated app, almost every single function call is going to require this boilerplate. Annoying.

reply


> if (err != nil) { return err; }

Yup; definitely a pattern.

reply


The big thing too, with the `if err != nil` pattern is that it's _good_ Go practice to do that, but it doesn't feel good to constantly be spamming a 3 line error check on every single statement.

I really don't like hopping into a codebase and seeing a 27-line function (uncommented, of course) with 21 of the lines being `if err != nil` checks

reply


> `if err != nil { return err }` is actually bad Go code, and not often written by good Go programmers.

Like the people who wrote the Go stdlib? Because that's filled with those - just look at the net/* packages.

reply


Still not seeing how this saves you from having to check if err != nil everywhere.

Though I suppose if this were another language it would be akin to a try catch around every line of code. Which in a way is great, but pretty labor intensive.

reply


I've been writing some gocode recently and huge chunk of code is

if err != nil ...

I know you can do if ; err!=nil but that not that much better and you end up in deeply nested if blocks.

i have to mentally block out err !=nil to read any gocode linearly. How is this acceptable, I don't get it.

https://blog.golang.org/errors-are-values

We recently scanned all the open source projects we could find and discovered that this snippet occurs only once per page or two

This seems false from my experience, def way more than 1 or 2 instances per page.

reply


Please be respectful, nobody is regurgitating anything. People are frustrated because half of their programs are if err != nil { return nil, somestruct{}, false, "", err }

reply


That's what the underscore is for, explicit ignore. And it's a huge code smell.

You instantly notice it because the if err != nil -template is missing after it =)

reply


I just don't see how multiple levels of

    if err:
        return nil, err
in the call stack makes things any clearer? Or how having many instances of that snippet scattered everywhere makes the code easier to read?

reply


Two. The URL is a constant that is guaranteed not to return an error. It is not brevity.

Anyways, the point is I don't understand the point of err != nil bashing here, given there are two programs in the article that only contain one error check each.

reply


it's not as if `if err != nil` doesn't clutter up the code!

reply


> One last thing with error handling. Everybody does if err!=nil. I tend to go the opposite way, if err==nil and nest these, if err isn't nil i drop out and deal with the error. If it is ok, it will return ok.

Don't you get "staircase of doom"?

    err := unsafe1()
    if err == nil {
        err = unsafe2()
        if err == nil {
            err = unsafe3()
            if err == nil {
                err = unsafe4()
                    if err == nil {
                    err = unsafe5()
                    if err == nil {
                        // ...
                    }
                }
            }
        }
    }

reply


It's the bane of Go code.

If you want to write it safely, you will have `if err != nil` everywhere.

This is normal and expected.

reply


It's nil and not null, and the pattern you'll see much more often (in my experience) is if res, err = func(); err != nil {}.

Checking for an error to be nil seems unusual, as you'd continue with your code in that situation.

And the code isn't that long, don't think it really bloats up the code.

reply


Let's remember that every function call that can return an error normally takes these three extra lines:

  if err != nil {
    return err
  }

reply


if err != nil { return nil, err }

code poetry right there. it's so good that you have to repeat this over and over again!

reply


#3 has always bothered me. I feel like:

   someString := "hello"
   someString, err := ReturnStringAndError("world")
   if err != nil {
      fmt.Println("there's no way this could happen")
   } else {
      fmt.Println(someString)
   }
Should produce an error.

reply


> You don't have compile time checks for errors.

I don't quite understand this statement. The compiler finds errors in my code all the time. Should it be evaluating something like `if err != nil`?

reply


Someone posted this chart[0] on the mailing list[1].

It pretty-prints a chart that shows the different nil comparisons, and what they result in (true, false, or n/a being an error caught by the compiler).

[0]: http://play.golang.org/p/7GohUdfIsD [1]: https://groups.google.com/d/topic/golang-nuts/zvqvEZk53Q0/di...

reply

next

Legal | privacy