3 ms·

Unlike C, Go isn't overloading what is returned, it has an extra param, and the language has been baked to handle doing like initialization and checks in single

Unlike C, Go isn't overloading what is returned, it has an extra param, and the language has been baked to handle doing like initialization and checks in single line if statements. It does force the developer who might actually have a clue what the exception is and how to fix it to handle it, but IMHO this is a good thing. Go forces lots of things like this (not using an import, won't compile; not using a variable, won't compile). Honestly, compared to the exception hellscapes I have had to deal with in Java and C++ --- it seems like the path of least surprise. Which incidentally has been my favorite things about Go, the low number of surprises. A lot of using Go in real work has gone against my expectations. There are a lot of things I initially saw as huge warts (lack of exceptions, generics and import versions), but I liked channels enough (Erlang background) to give it a shot. So far, I have been delighted by using it as a stack (build cycle, deploy method, terse C'ish syntax).

TylerE 13y ago
To make one correction, it isn't an "extra param", go has full support for multiple return values, full stop.
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.
Teckla 13y ago
Unlike C, Go isn't overloading what is returned In C, you can write code that doesn't overload errors and return values; e.g., err = someFunction(&returnValue, param1, param2, param3); I'm not saying this is common -- and in fact the standard C library does a lot of the overloading you're talking about -- but for your own code and functions, you can separate out errors and return values, as shown above.

TylerE 13y ago

To make one correction, it isn't an "extra param", go has full support for multiple return values, full stop.

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.

Teckla 13y ago

Unlike C, Go isn't overloading what is returned In C, you can write code that doesn't overload errors and return values; e.g., err = someFunction(&returnValue, param1, param2, param3); I'm not saying this is common -- and in fact the standard C library does a lot of the overloading you're talking about -- but for your own code and functions, you can separate out errors and return values, as shown above.