6 ms·

What really gets me about go is that it's lame, manual error handling sucks, causing it to be smack dab in a middle area between my current languages of c++ and

What really gets me about go is that it's lame, manual error handling sucks, causing it to be smack dab in a middle area between my current languages of c++ and python. If you don't believe me, note that golang.org's home page example lacks error handling (huge fail). In c++, I like the predictable destructor model of memory cleanup, and am willing to pay the manual error checking price (too scared to write exception safe code in c++). But I like to put as much complex logic in python code, due to its nice exception handling and GC. If GO had a more flexible exception model, which by the way does not require forward jumping try/catch constructs, making it easier for people to write 'crash only' error handling without boiler plate, I might consider it. But for me, it's currently typecast as a firmly middle of the road feature set.

acdha 13y ago
That optional error handling still boggles me, particularly since http://golang.org/doc/faq#exceptions http://golang.org/doc/faq#exceptions makes it clear that they undervalued the the other major family of problems affecting C programs: programmers not checking return codes in often-exploitable ways. I can understand not going the full Java/C++-level overhead (although Python is a great example of how that doesn't need to be so tedious in practice) but it still amazes me that simply importing something you don't use is a fatal compiler error but the classic "res, _ = something()" responsibility shirk you see all over the Go world doesn't even get a warning. Maybe Go 2.0 could make the compiler simply do the equivalent of inserting an `if err != nil { panic("Unhandled error at FILE:LINE") }` block after any statement which can return an error and doesn't already have a check. That'd satisfy the low-overhead, predictable flow-control crowd while making the language much safer for large systems in practice. (n.b.: lest that seem like too harsh a condemnation, I actually rather like Go as a highly appealing alternative to C: the fact that they got so many things right — gofmt alone deserves a medal — makes the minimal error handling feel like a surprising oversight.)
- ansible 13y ago
  With a parser for Go in the standard library, it would be easy enough to write a source scanner that looked for unhandled error returns.
  - acdha 13y ago
    This is true but that's a non-trivial task even before you get to the question of running it on all third-party code and getting the upstream to patch it. This would solve the problem only in the same way that static analysis tools mean C code no longer has buffer overflows or type conversion errors.
mietek 13y ago
It's interesting to see you arrive at 'crash-only' error handling from C++. This method of error handling, usually known as 'let-it-crash', is arguably Erlang's greatest strength. Unfortunately, the designers of Go hadn't quite managed to crib this part of Erlang.

acdha 13y ago

That optional error handling still boggles me, particularly since http://golang.org/doc/faq#exceptions http://golang.org/doc/faq#exceptions makes it clear that they undervalued the the other major family of problems affecting C programs: programmers not checking return codes in often-exploitable ways. I can understand not going the full Java/C++-level overhead (although Python is a great example of how that doesn't need to be so tedious in practice) but it still amazes me that simply importing something you don't use is a fatal compiler error but the classic "res, _ = something()" responsibility shirk you see all over the Go world doesn't even get a warning. Maybe Go 2.0 could make the compiler simply do the equivalent of inserting an `if err != nil { panic("Unhandled error at FILE:LINE") }` block after any statement which can return an error and doesn't already have a check. That'd satisfy the low-overhead, predictable flow-control crowd while making the language much safer for large systems in practice. (n.b.: lest that seem like too harsh a condemnation, I actually rather like Go as a highly appealing alternative to C: the fact that they got so many things right — gofmt alone deserves a medal — makes the minimal error handling feel like a surprising oversight.)

ansible 13y ago
With a parser for Go in the standard library, it would be easy enough to write a source scanner that looked for unhandled error returns.
- acdha 13y ago
  This is true but that's a non-trivial task even before you get to the question of running it on all third-party code and getting the upstream to patch it. This would solve the problem only in the same way that static analysis tools mean C code no longer has buffer overflows or type conversion errors.

mietek 13y ago

It's interesting to see you arrive at 'crash-only' error handling from C++. This method of error handling, usually known as 'let-it-crash', is arguably Erlang's greatest strength. Unfortunately, the designers of Go hadn't quite managed to crib this part of Erlang.