News for hackers. Stuff that matters.
Re:On Go by throwit1979 on Sunday June 02, 2013 @10:35AM (#5808649)
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 _.
Re:On Go by nknighthb on Sunday June 02, 2013 @12:02PM (#5808965)
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

Re:On Go by pcwalton on Sunday June 02, 2013 @01:24PM (#5809313)
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

(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.)

Re:On Go by MetaCosm on Sunday June 02, 2013 @03:46PM (#5809809)
Go AST is something that I think will really help as it grows for writing great tooling.
Re:On Go by cpeterso on Sunday June 02, 2013 @03:49PM (#5809823)
To allow lazy error checking without losing safety, perhaps Go could special case _ so that error codes assigned to _ abort for failure values.
Re:On Go by nknighthb on Sunday June 02, 2013 @04:00PM (#5809875)
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?

Re:On Go by coldtea on Sunday June 02, 2013 @07:36PM (#5810541)
Could just be "!" by itself no?
Re:On Go by pcwalton on Sunday June 02, 2013 @04:57PM (#5810060)
They can't change that at this stage without breaking the Go 1.0 compatibility promise.