5 ms·

>We recently scanned all the open source projects we could find and discovered that this snippet occurs only once per page or two, less often than some would ha

by rtpg 12y ago

>We recently scanned all the open source projects we could find and discovered that this snippet occurs only once per page or two, less often than some would have you believe. once per page? that's once per 30 or so lines. 2 or 3 percent of the code is this same repetitive structure? Also, only takes one time to forget this for everything to fall apart. We've spent so much time trying to deal with uninit'd pointers and things like that on the language level, and here we have something that's much simpler, yet super repetitive and should be easy to catch on compile time. Maybe I'm just a bad programmer, but I really prefer the Java "force you to catch exception" model much more to this. >It's worth stressing that whatever the design, it's critical that the program check the errors however they are exposed. If it's critical to check the errors, I think that it's worth writing language rules in a way to force people to write a "has error " code path (think pattern matching). I get go is trying to be as small of a core as possible, but I think there's a lot of value in extra compiler checks (with no runtime cost!) to catch this sort of thing.

twotwotwo 12y ago
> I really prefer the Java "force you to catch exception" model much more to this. https://github.com/kisielk/errcheck/ https://github.com/kisielk/errcheck/ will tell you if you silently discard the `err` value (though you can still explicitly assign it to _ to ignore). Seems worth using for a lot of projects.
- burke 12y ago
  We use errcheck for all the Go code we write at Shopify. In many cases, we compile the project using a script that fails if errcheck isn't clean, effectively turning into a "you are forced to catch the exception" sort of idea. It's nice because it's still easy to ignore the err in certain circumstances (e.g. the occasional `_ = f.Close()`), but there's always a visual marker to remind you.
  - jroesch 12y ago
    The above comments are just pointing out that the compiler should do this for you. It is great that there are third party tools for this, but a simple lint like this should come for free, especially when this is the endorsed error handling policy.
    - enneff 12y ago
      Not everything belongs in the compiler. Go's "vet" tool might be the place for something like this. But, honestly, I have been writing Go code for 5 years and I can count the number of times that "didn't check the error" was the cause of a bug on one hand.
      - twotwotwo 12y ago
        Agree on not in the compiler. A ton of folks seem to dig errcheck; having that sort of check in vet or in the Go distro somehow seems worthwhile. (Of course, if I feel that way, maybe I should put some effort where my mouth is and try and start on a patch. :)
- Intermernet 12y ago
  I'm actually quite surprised this functionality hasn't made it into "go vet" yet. It would be useful to be able to do this without a 3rd party utility (although all respect to kisielk for producing such a useful tool).
  - rtpg 12y ago
    pleasantly surprised that you could write go tooling to check this, I hope the team is willing to pull things like this in.
deleted 12y ago
[deleted]
bsdetector 12y ago
> that's once per 30 or so lines. 2 or 3 percent of the code ... I really prefer the Java "force you to catch exception" model much more to this. And that 2%-3% doesn't include where errors should have been checked but were not. For instance run programs without stdout ("./program 1>&-") and most Go console programs will just happily write to nowhere whereas almost all Java ones error out immediately. Closing stdout doesn't often matter, but sometimes things like this are important. I don't understand how in the 2010s it's okay to make a language with worse reliability. And worse "JavaDoc" equivalent. Go should be better than C and Java in every category and it's just not better in way too many.
- sangnoir 12y ago
  Language design is about trade-offs. Broadly speaking: being good in one category means being bad in another.
  - TheDong 12y ago
    While your comment is sort of true, it's not applicable here really. We know how to handle errors better than this. Go's error handling is C style. We've since found exceptions, Maybes, and friends which are very powerful. What you said implies that when Rust chooses to use Maybes they're somehow being bad at something. That's simply false; computer science as a field has advanced and one of these advancements (not even that recent of one) is improved understandings of how strong type systems can be used to make code, including errors, safer. Go completely ignores this of course and they're not doing it for a tradeoff that I can see. They gain nothing in terms of performance for not having this type (everything is already a reflect/Value anyways, so much for not having the baggage that you'd need for generics) and everything in terms of having a worse language. Being good at something doesn't instantly mean you're bad at something else. In fact, I wouldn't even claim that's the general case. If you disagree, you're welcome to point out the tradeoffs at work here. I think your comment is just a vaguery that is completely untrue in this instance.
    - enneff 12y ago
      The corresponding loss to Rust's gain is language complexity.
cmelbye 12y ago
> here we have something that's much simpler, yet super repetitive and should be easy to catch on compile time. It is easy to catch on compile time. https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck
curun1r 12y ago
Go's error handling is only a problem because of other missing features...algebraic types and/or generics. With either of those features, you could implement two-track, functional composition with a single bind method. That would go a long way towards only having to write your "if err != nil" once rather than once per function invocation. Alas, the lack of those other features leads to articles like this one that offer unnatural ways of avoiding something that is pretty much idiomatic in the language.

by rtpg 12y ago

twotwotwo 12y ago

> I really prefer the Java "force you to catch exception" model much more to this. https://github.com/kisielk/errcheck/ https://github.com/kisielk/errcheck/ will tell you if you silently discard the `err` value (though you can still explicitly assign it to _ to ignore). Seems worth using for a lot of projects.

burke 12y ago
We use errcheck for all the Go code we write at Shopify. In many cases, we compile the project using a script that fails if errcheck isn't clean, effectively turning into a "you are forced to catch the exception" sort of idea. It's nice because it's still easy to ignore the err in certain circumstances (e.g. the occasional `_ = f.Close()`), but there's always a visual marker to remind you.
- jroesch 12y ago
  The above comments are just pointing out that the compiler should do this for you. It is great that there are third party tools for this, but a simple lint like this should come for free, especially when this is the endorsed error handling policy.
  - enneff 12y ago
    Not everything belongs in the compiler. Go's "vet" tool might be the place for something like this. But, honestly, I have been writing Go code for 5 years and I can count the number of times that "didn't check the error" was the cause of a bug on one hand.
    - twotwotwo 12y ago
      Agree on not in the compiler. A ton of folks seem to dig errcheck; having that sort of check in vet or in the Go distro somehow seems worthwhile. (Of course, if I feel that way, maybe I should put some effort where my mouth is and try and start on a patch. :)
Intermernet 12y ago
I'm actually quite surprised this functionality hasn't made it into "go vet" yet. It would be useful to be able to do this without a 3rd party utility (although all respect to kisielk for producing such a useful tool).
- rtpg 12y ago
  pleasantly surprised that you could write go tooling to check this, I hope the team is willing to pull things like this in.

deleted 12y ago

[deleted]

bsdetector 12y ago

> that's once per 30 or so lines. 2 or 3 percent of the code ... I really prefer the Java "force you to catch exception" model much more to this. And that 2%-3% doesn't include where errors should have been checked but were not. For instance run programs without stdout ("./program 1>&-") and most Go console programs will just happily write to nowhere whereas almost all Java ones error out immediately. Closing stdout doesn't often matter, but sometimes things like this are important. I don't understand how in the 2010s it's okay to make a language with worse reliability. And worse "JavaDoc" equivalent. Go should be better than C and Java in every category and it's just not better in way too many.

sangnoir 12y ago
Language design is about trade-offs. Broadly speaking: being good in one category means being bad in another.
- TheDong 12y ago
  While your comment is sort of true, it's not applicable here really. We know how to handle errors better than this. Go's error handling is C style. We've since found exceptions, Maybes, and friends which are very powerful. What you said implies that when Rust chooses to use Maybes they're somehow being bad at something. That's simply false; computer science as a field has advanced and one of these advancements (not even that recent of one) is improved understandings of how strong type systems can be used to make code, including errors, safer. Go completely ignores this of course and they're not doing it for a tradeoff that I can see. They gain nothing in terms of performance for not having this type (everything is already a reflect/Value anyways, so much for not having the baggage that you'd need for generics) and everything in terms of having a worse language. Being good at something doesn't instantly mean you're bad at something else. In fact, I wouldn't even claim that's the general case. If you disagree, you're welcome to point out the tradeoffs at work here. I think your comment is just a vaguery that is completely untrue in this instance.
  - enneff 12y ago
    The corresponding loss to Rust's gain is language complexity.

cmelbye 12y ago

> here we have something that's much simpler, yet super repetitive and should be easy to catch on compile time. It is easy to catch on compile time. https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck

curun1r 12y ago

Go's error handling is only a problem because of other missing features...algebraic types and/or generics. With either of those features, you could implement two-track, functional composition with a single bind method. That would go a long way towards only having to write your "if err != nil" once rather than once per function invocation. Alas, the lack of those other features leads to articles like this one that offer unnatural ways of avoiding something that is pretty much idiomatic in the language.