4 ms·

Go’s treatment of errors as values has served us well over the last decade. Has it? As a Java developer who needed to write something in Go, this has been quit

Go’s treatment of errors as values has served us well over the last decade. Has it? As a Java developer who needed to write something in Go, this has been quite a frustration for me, personally. In Java, when I get a 100-line stacktrace error, my IDE analyzes it for me and I can click through the code and follow what's happening. In Go, I get a string from the developer. Hmm...

halfer53 7y ago
I agree, a simple string from the error doesn't help debugging at all. This happens a lot in production environment, in which developers are too lazy to write any useful debugging information, all we got left is a simple "get_foo() returns error" in the log, it doesn't help with the debugging at all !!!
- nomel 7y ago
  Sound familiar. I had a boss that wanted to clean up our error messages and stack traces from our library/api and make them cleaner and more useful. To make it cleaner, he wanted to absorb the whole stack for any error raised in our library and only print the error text. To make them more useful and helpful, he wanted us also include some guides on how to debug and solve the problem, based on the error, in the error text. Fortunately I was able to convince him this would make things difficult for everyone, in a calm collective way.
  - twic 7y ago
    How do people come up with ideas like this?!
    - LilBytes 7y ago
      Step 1) hire a manager for people management skills and no technical nouse Step 2) Hire a lot of yes men At least in OPs response, their manager defers to those who know better.
JulianMorrison 7y ago
That's bad Go design. An API where the particular nature of the error matters, should declare error constants and use the "Is" mechanism. You shouldn't be unpicking the internals with an IDE, you should be getting something you can work with, right there.
- coldtea 7y ago
  >That's bad Go design. I think that's the parent's point. Though, not that that is bad Go API design on behalf of the library authors (as you imply), but that that is a sign of Go's own bad design -- the fact that it leaves it to programmers own devices to get their API design right with respect to errors...
- aikah 7y ago
  > That's bad Go design. An API where the particular nature of the error matters, should declare error constants and use the "Is" mechanism. You shouldn't be unpicking the internals with an IDE, you should be getting something you can work with, right there. AKA roll your own stack trace library. That's what "errors" package and co are. That's not "bad God design". It's just not Go's problem, as deemed by Go designers. Thus criticizing that trade-off is fair, like any trade-offs.
  - apta 7y ago
    So we're back to C where each project rolls out its own string implementation. This really shows the mentality of the golang authors.
    - aikah 7y ago
      I mean at that point if you are still using Go, then you agree with whatever Golang authors tell you. Most people who were sceptical about Go or were vocal about trying to improve the language moved on to something else, because they faced a wall of contempt. The whole Go 2 stunt is more an "idea parking lot" than anything else.
  - _ph_ 7y ago
baby 7y ago
Java is the worst language to do error handling. Let's just throw an exception and hope that somethings catches it!
- tsimionescu 7y ago
  Go is much better! Let's just return an error, and hope someone looks at it. Oh, and if that hope was wrong in Java? Thread does, nice call stack in logs. In Go? Well, the program will go on with some default - value struct, most likely.
  - baby 7y ago
    > Let's just return an error, and hope someone looks at it Some people would argue that this is what linters do: warn you when you don't check errors as return values. I'm not sure what's the best solution here, and I don't think any language handles this out of the box (without linters) > and if that hope was wrong in Java? Denial of service But I get your point though, errors are hard and I think the only language that I've seen doing something good with them is Erlang. You just expect errors to crash your actors, and you design to recover quickly from any type of crash.

halfer53 7y ago

I agree, a simple string from the error doesn't help debugging at all. This happens a lot in production environment, in which developers are too lazy to write any useful debugging information, all we got left is a simple "get_foo() returns error" in the log, it doesn't help with the debugging at all !!!

nomel 7y ago
Sound familiar. I had a boss that wanted to clean up our error messages and stack traces from our library/api and make them cleaner and more useful. To make it cleaner, he wanted to absorb the whole stack for any error raised in our library and only print the error text. To make them more useful and helpful, he wanted us also include some guides on how to debug and solve the problem, based on the error, in the error text. Fortunately I was able to convince him this would make things difficult for everyone, in a calm collective way.
- twic 7y ago
  How do people come up with ideas like this?!
  - LilBytes 7y ago
    Step 1) hire a manager for people management skills and no technical nouse Step 2) Hire a lot of yes men At least in OPs response, their manager defers to those who know better.

JulianMorrison 7y ago

That's bad Go design. An API where the particular nature of the error matters, should declare error constants and use the "Is" mechanism. You shouldn't be unpicking the internals with an IDE, you should be getting something you can work with, right there.

coldtea 7y ago
>That's bad Go design. I think that's the parent's point. Though, not that that is bad Go API design on behalf of the library authors (as you imply), but that that is a sign of Go's own bad design -- the fact that it leaves it to programmers own devices to get their API design right with respect to errors...
aikah 7y ago
> That's bad Go design. An API where the particular nature of the error matters, should declare error constants and use the "Is" mechanism. You shouldn't be unpicking the internals with an IDE, you should be getting something you can work with, right there. AKA roll your own stack trace library. That's what "errors" package and co are. That's not "bad God design". It's just not Go's problem, as deemed by Go designers. Thus criticizing that trade-off is fair, like any trade-offs.
- apta 7y ago
  So we're back to C where each project rolls out its own string implementation. This really shows the mentality of the golang authors.
  - aikah 7y ago
    I mean at that point if you are still using Go, then you agree with whatever Golang authors tell you. Most people who were sceptical about Go or were vocal about trying to improve the language moved on to something else, because they faced a wall of contempt. The whole Go 2 stunt is more an "idea parking lot" than anything else.
- _ph_ 7y ago

baby 7y ago

Java is the worst language to do error handling. Let's just throw an exception and hope that somethings catches it!

tsimionescu 7y ago
Go is much better! Let's just return an error, and hope someone looks at it. Oh, and if that hope was wrong in Java? Thread does, nice call stack in logs. In Go? Well, the program will go on with some default - value struct, most likely.
- baby 7y ago
  > Let's just return an error, and hope someone looks at it Some people would argue that this is what linters do: warn you when you don't check errors as return values. I'm not sure what's the best solution here, and I don't think any language handles this out of the box (without linters) > and if that hope was wrong in Java? Denial of service But I get your point though, errors are hard and I think the only language that I've seen doing something good with them is Erlang. You just expect errors to crash your actors, and you design to recover quickly from any type of crash.