3 ms·

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.s

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 http://talks.golang.org/2014/readability.slide#11 In this example, have to check error 3 times to write 4 lines of code.

libria 12y ago
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.
- lclarkmichalek 12y ago
  Given that every single error check there is just passing up the error, is it really that different from having exceptions that propagate along with RAII style resource cleanup? The vast vast vast majority of Go code simply propagates errors.
  - sagichmal 12y ago
    > Given that every single error check there is just > passing up the error, is it really that different from > having exceptions that propagate along with RAII style > resource cleanup? Yes, it's fundamentally different. The whole point is to make those error blocks visible, so future maintainers are forced to deal with the reality that those invocations are fallible. Maybe there's a way to make the error handling less verbose, but hiding it altogether would subvert that explicit language design goal.
    - lclarkmichalek 12y ago
      Except, you know, just mindlessly typing out "if err != nil { return }" does not somehow force enlightenment upon the user. The error blocks are so uniform in their banality that future maintainers treat them the same way that error handling is treated in every other language.
      - invisible 12y ago
        The fundamental difference is that each separate error is accounted for rather than 4 lines all being treated as error points so you never know which could throw.
- justinsb 12y ago
  If you use try-with-resources in Java 7, you don't need to write any exception handling. 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!
vendakka 12y ago
I started out thinking this was a little tedious and even came up with a little library [1] to use the panic-recover style handling within a package [2]. 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 https://godoc.org/github.com/surullabs/fault [2] https://golang.org/doc/effective_go.html#recover https://golang.org/doc/effective_go.html#recover

libria 12y ago

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.

lclarkmichalek 12y ago
Given that every single error check there is just passing up the error, is it really that different from having exceptions that propagate along with RAII style resource cleanup? The vast vast vast majority of Go code simply propagates errors.
- sagichmal 12y ago
  > Given that every single error check there is just > passing up the error, is it really that different from > having exceptions that propagate along with RAII style > resource cleanup? Yes, it's fundamentally different. The whole point is to make those error blocks visible, so future maintainers are forced to deal with the reality that those invocations are fallible. Maybe there's a way to make the error handling less verbose, but hiding it altogether would subvert that explicit language design goal.
  - lclarkmichalek 12y ago
    Except, you know, just mindlessly typing out "if err != nil { return }" does not somehow force enlightenment upon the user. The error blocks are so uniform in their banality that future maintainers treat them the same way that error handling is treated in every other language.
    - invisible 12y ago
      The fundamental difference is that each separate error is accounted for rather than 4 lines all being treated as error points so you never know which could throw.
justinsb 12y ago
If you use try-with-resources in Java 7, you don't need to write any exception handling. 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!

vendakka 12y ago

I started out thinking this was a little tedious and even came up with a little library [1] to use the panic-recover style handling within a package [2]. 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 https://godoc.org/github.com/surullabs/fault [2] https://golang.org/doc/effective_go.html#recover https://golang.org/doc/effective_go.html#recover