3 ms·

The problem with this "forcing" that go does is that it ALSO includes _, which means it's inevitable that lazy developers will get tired of handling error and j

by throwit1979 13y ago

The problem with this "forcing" that go does is that it ALSO includes _, which means it's inevitable that lazy developers will get tired of handling error and just shunt it into _.

nknighthb 13y ago
You can't stop people from being lazy. Look at all the Java and Python code that forcefully ignores exceptions. It is something that can be caught with static analysis, however. Someone recently put together an appropriate tool[1] for Go, in fact. It seems to work very well. [1]https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck
- pcwalton 13y ago
  To be fair, the ability to use static analysis for error code checking is not something that is unique to Go. There was a paper recently on doing this for C (which found hundreds of bugs in the Linux kernel due to incorrect error code handling): http://pages.cs.wisc.edu/~liblit/ghc-2011/ghc-2011.pdf http://pages.cs.wisc.edu/~liblit/ghc-2011/ghc-2011.pdf (Incidentally, the hard part of this analysis is not verifying that you checked the error, it's verifying that you propagated the error codes properly—that requires analyzing higher-order control flow.)
- MetaCosm 13y ago
  Go AST is something that I think will really help as it grows for writing great tooling.
cpeterso 13y ago
To allow lazy error checking without losing safety, perhaps Go could special case _ so that error codes assigned to _ abort for failure values.
- nknighthb 13y ago
  I would love something like this, actually. I'm not sure I like the idea of special casing _ specifically, but a similarly concise way of saying "if this fails, this thread of execution is FUBAR" would be great. "!!", maybe?
  - coldtea 13y ago
    Could just be "!" by itself no?
- pcwalton 13y ago
  They can't change that at this stage without breaking the Go 1.0 compatibility promise.

3 ms·

The problem with this "forcing" that go does is that it ALSO includes _, which means it's inevitable that lazy developers will get tired of handling error and j

by throwit1979 13y ago

The problem with this "forcing" that go does is that it ALSO includes _, which means it's inevitable that lazy developers will get tired of handling error and just shunt it into _.

nknighthb 13y ago
You can't stop people from being lazy. Look at all the Java and Python code that forcefully ignores exceptions. It is something that can be caught with static analysis, however. Someone recently put together an appropriate tool[1] for Go, in fact. It seems to work very well. [1]https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck
- pcwalton 13y ago
  To be fair, the ability to use static analysis for error code checking is not something that is unique to Go. There was a paper recently on doing this for C (which found hundreds of bugs in the Linux kernel due to incorrect error code handling): http://pages.cs.wisc.edu/~liblit/ghc-2011/ghc-2011.pdf http://pages.cs.wisc.edu/~liblit/ghc-2011/ghc-2011.pdf (Incidentally, the hard part of this analysis is not verifying that you checked the error, it's verifying that you propagated the error codes properly—that requires analyzing higher-order control flow.)
- MetaCosm 13y ago
  Go AST is something that I think will really help as it grows for writing great tooling.
cpeterso 13y ago
To allow lazy error checking without losing safety, perhaps Go could special case _ so that error codes assigned to _ abort for failure values.
- nknighthb 13y ago
  I would love something like this, actually. I'm not sure I like the idea of special casing _ specifically, but a similarly concise way of saying "if this fails, this thread of execution is FUBAR" would be great. "!!", maybe?
  - coldtea 13y ago
    Could just be "!" by itself no?
- pcwalton 13y ago
  They can't change that at this stage without breaking the Go 1.0 compatibility promise.