61–70 of 93 posts
Earlier quoted context omitted.
What's the practical problem of this, though? The (varname, err := thing) pattern is sprinkled all throughout the language, enough to where it should be instinctive for a coder to check the err value when doing anything that could fail.
A major hit to readability. Every call site where you want to check for an error requires adding another level of nesting.
Earlier quoted context omitted.
A major hit to readability. Every call site where you want to check for an error requires adding another level of nesting.
That's a different issue. Pattern-matching a sum-type value, though safer, would be "noise" too.
I don't get where is the bug in this code: http://talks.golang.org/2014/readability.slide#10
In the original code if out.Close() returns an error, run() will return nil. The revised code sets `err` to the returned error from out.Close(), in case the error from os.Create(*output) is nil. Simply spoken, the original code will suppress the error from out.Close().
I think this is tricky in any language.
As I go from normal Go style to idiomatic Go style, I find more error checks. That is annoying when your code grows. http://talks.golang.org/2014/readability.slide#11 In this example, have to check error 3 times to write 4 lines of code.
However, after a few months of writing code using that model, I find that I don't really like it and prefer the if err != nil model much more.
While this can appear to be a little tedious, I've found it extremely useful once I started checking code coverage in my tests. It makes it very clear which exceptional cases you aren't testing. This in turn makes it obvious how well tested the code is. I know from looking at my code coverage what kind failures I'm handling properly and which ones I'm delegating to the caller. This allows for better documentation where API users know what failure modes to expect.
[1] https://godoc.org/github.com/surullabs/fault [2] https://golang.org/doc/effective_go.html#recover
I've never known a language with so much discussion on why what you are doing isn't idiomatic as Go. I'm enjoying using Go for the few small services I'm using it for but it seems that a language which has to constantly fight it's users to reinforce what it considers idiomatic has some core issues.
Or, it could be a result of Go making use of some novel approaches that a lot of programmers are not used to.
As I go from normal Go style to idiomatic Go style, I find more error checks. That is annoying when your code grows. http://talks.golang.org/2014/readability.slide#11 In this example, have to check error 3 times to write 4 lines of code.
In Java, I'd have to write 3 catch blocks. It's possible to write a blanket catch, toss it up to higher levels and make it someone else's problem. I vaguely recall this being against Pike's vision of what "exceptional" means and he wanted a language that forces developers to think of disk/network failure as a very common case.
The function would be '... throws IOException'. That seems to satisfy the "think of disk/network failure as a very common case" design goal with minimal boilerplate. That brings up a separate discussion on checked vs unchecked exceptions, but I guess we can save that one for comparisons against a language with unchecked exceptions!
Earlier quoted context omitted.
A major hit to readability. Every call site where you want to check for an error requires adding another level of nesting.
That's a different issue. Pattern-matching a sum-type value, though safer, would be "noise" too.
Earlier quoted context omitted.
I disagree, and saying "That is the way it is done in C" doesn't mean that it's the right way. When I see code like this I will assume that it's going to check every condition: if !complete { // do something } if stat, ok := r.Object.(*api.Status); ok && stat.Code != 0 { // do something } if r.Created { // do something } If the first condition matching causes the second, third, nth condition to not be checked then wh…
If you are religious about single-return style --- and I was an observant practitioner of it until recently --- you simply aren't going to like Golang. For that matter, if you hate C programming --- not in the sense of "C is dangerous and error prone" and more in the sense of "I hate the way I feel when I write C code", you also aren't going to like Golang. The former issue grinds on me a bit, though I'm coming to ap…
Earlier quoted context omitted.
That's a different issue. Pattern-matching a sum-type value, though safer, would be "noise" too.
Correct me if I'm wrong, but I believe with sum types you can chain together multiple calls then pattern match once at the end. In Go you have to check at each call.
Earlier quoted context omitted.
Feel free to enlighten us specifically about how they are better.
In Go, you're not returning a sum type, so it's down to the programmer to remember that the "real" return value is likely toxic waste when its copassenger the error return value is non-nil.