8 ms·

t.Helper() is certainly going to be very useful. I often implement functions like: func testServer(t *testing.T, port int) { ...do stuff...

by alpb 9y ago

t.Helper() is certainly going to be very useful. I often implement functions like: func testServer(t *testing.T, port int) { ...do stuff... if err != nil { t.Fatalf("failed to start server: %+v", err) } } similarly you can have func assertMapEquals(t *testing.T, a, b map[string]int) It lets you hide such helper methods from the test failure's stack trace (where t.Fatal is actually called), making test errors more readable.

azinman2 9y ago
Yes indeed this is totally awesome. It’s a problem that occurs on any platform, and not only for testing. I often see this problem with logging as well, where some validation/helper function logs an error separate from the context it occurred in, potentially making it hard to trace without a stacktrace logged as well.
- throw4625 9y ago
  This is the biggest problem with Go errors and one of my biggest gripes with the language. Exceptions have stacktraces that give you context about where the error originated. Go errors don't have this and it costs me a lot of time debugging things.https://godoc.org/github.com/pkg/errors https://godoc.org/github.com/pkg/errors helps, but it's still more of a pain than it should be.
  - cpuguy83 9y ago
    Errors can be anything. It's just an interface.
    - stouset 9y ago
      Except you don't get to control the specific error type returned by packages you import. So sure, you could get stack traces for your code, but not for your dependencies. It infuriates me when go proponents try and sweep bad language decisions under the rug with half-fixes. https://twitter.com/codebeeCA/status/885302657178587136 https://twitter.com/codebeeCA/status/885302657178587136
      - eljimmy 9y ago
        It's worth noting that nobody is saying you can't fix that problem in your dependencies. When you rely on dependencies you have to expect that not all of them will carry the same quality of code which you create yourself.
      - randomdata 9y ago
        To be fair, the Go authors have always strongly promoted that you fork and maintain your dependencies. That may be a bad operational decision (outside of Google), but is technically unrelated to the language itself. Mind you, if third party code needs debugging, you're going to have to fork it in order to apply your fixes in a timely manner anyway. Perhaps their stance is not as crazy as it may originally seem.
        fauigerzigerk 9y ago
        Can you point me to a quote where Go authors have encouraged people to fork a third party library in order to insert better error handling code? I don't want to insult anyone, but this seems like an utterly insane software engineering practice to me. It means you can't just update to the next version of that library any longer. You're taking it upon yourself to review and patch every single new version of that library. Manually.
        randomdata 9y ago
        See: Any discussion related to go get and its design motivations. Even vendoring, which was added to the tooling later, is built on the idea of keeping your own fork. It just simplifies the forking process for people who do not work like Google does, where each fork is shared company-wide.
        stouset 9y ago
        GP is right: this is insane. Not only are people here suggesting that you fork your dependencies to add stack traces to errors, which is a problem no other modern language seems to have, but it's also going to be a security disaster when some common package is found to have a vulnerability and ten percent of projects ever bother to update it. I feel like I've entered some sort of bizarro world where everyone has forgotten that programming doesn't have to suck and pretends that none of this is a problem.
    - eloff 9y ago
      Which to be clear, is a language design mistake. Go would be a much more productive and friendly language if errors would just have stack traces on them when they're created. There's no reason to have the poor developer adding dozens of debug prints all over his (and sometimes third-party) code manually into every place that could have returned the error just to try and discern where it comes from. Or grepping for strings in the error message, or throwing darts at printouts of the source. That's just a massive step backwards from what we've had since the 80s and 90s. I know Go prides itself on being simple, but really the errors are too simple and we're all worse off because of it.
      - 9t3h4r3o5w1a4w2 9y ago
        The problem is that Go errors are just a convention, they are not a feature of Go. It's just an interface, it could have been called FOO it wouldn't have made a difference. Go has exceptions, they are called "panic" by they are inferior to Java in the way they are handled.
        eloff 9y ago
        I know they're just a convention, but that was a mistake. It should have had more first-class language support so that they have stacktraces at least. I'm seriously beginning to think that even with the limitations, panic is a better error handling mechanism for all exceptional error cases. At least it has stacktraces and doesn't clutter the code with error boilerplate. I don't think I'd be able to convince anyone of that on a real project though, I'd have to try it on a personal project.

by alpb 9y ago

azinman2 9y ago

Yes indeed this is totally awesome. It’s a problem that occurs on any platform, and not only for testing. I often see this problem with logging as well, where some validation/helper function logs an error separate from the context it occurred in, potentially making it hard to trace without a stacktrace logged as well.

throw4625 9y ago
This is the biggest problem with Go errors and one of my biggest gripes with the language. Exceptions have stacktraces that give you context about where the error originated. Go errors don't have this and it costs me a lot of time debugging things.https://godoc.org/github.com/pkg/errors https://godoc.org/github.com/pkg/errors helps, but it's still more of a pain than it should be.
- cpuguy83 9y ago
  Errors can be anything. It's just an interface.
  - stouset 9y ago
    Except you don't get to control the specific error type returned by packages you import. So sure, you could get stack traces for your code, but not for your dependencies. It infuriates me when go proponents try and sweep bad language decisions under the rug with half-fixes. https://twitter.com/codebeeCA/status/885302657178587136 https://twitter.com/codebeeCA/status/885302657178587136
    - eljimmy 9y ago
      It's worth noting that nobody is saying you can't fix that problem in your dependencies. When you rely on dependencies you have to expect that not all of them will carry the same quality of code which you create yourself.
    - randomdata 9y ago
      To be fair, the Go authors have always strongly promoted that you fork and maintain your dependencies. That may be a bad operational decision (outside of Google), but is technically unrelated to the language itself. Mind you, if third party code needs debugging, you're going to have to fork it in order to apply your fixes in a timely manner anyway. Perhaps their stance is not as crazy as it may originally seem.
      - fauigerzigerk 9y ago
        Can you point me to a quote where Go authors have encouraged people to fork a third party library in order to insert better error handling code? I don't want to insult anyone, but this seems like an utterly insane software engineering practice to me. It means you can't just update to the next version of that library any longer. You're taking it upon yourself to review and patch every single new version of that library. Manually.
        randomdata 9y ago
        See: Any discussion related to go get and its design motivations. Even vendoring, which was added to the tooling later, is built on the idea of keeping your own fork. It just simplifies the forking process for people who do not work like Google does, where each fork is shared company-wide.
        stouset 9y ago
        GP is right: this is insane. Not only are people here suggesting that you fork your dependencies to add stack traces to errors, which is a problem no other modern language seems to have, but it's also going to be a security disaster when some common package is found to have a vulnerability and ten percent of projects ever bother to update it. I feel like I've entered some sort of bizarro world where everyone has forgotten that programming doesn't have to suck and pretends that none of this is a problem.
  - eloff 9y ago
    Which to be clear, is a language design mistake. Go would be a much more productive and friendly language if errors would just have stack traces on them when they're created. There's no reason to have the poor developer adding dozens of debug prints all over his (and sometimes third-party) code manually into every place that could have returned the error just to try and discern where it comes from. Or grepping for strings in the error message, or throwing darts at printouts of the source. That's just a massive step backwards from what we've had since the 80s and 90s. I know Go prides itself on being simple, but really the errors are too simple and we're all worse off because of it.
    - 9t3h4r3o5w1a4w2 9y ago
      The problem is that Go errors are just a convention, they are not a feature of Go. It's just an interface, it could have been called FOO it wouldn't have made a difference. Go has exceptions, they are called "panic" by they are inferior to Java in the way they are handled.
      - eloff 9y ago
        I know they're just a convention, but that was a mistake. It should have had more first-class language support so that they have stacktraces at least. I'm seriously beginning to think that even with the limitations, panic is a better error handling mechanism for all exceptional error cases. At least it has stacktraces and doesn't clutter the code with error boilerplate. I don't think I'd be able to convince anyone of that on a real project though, I'd have to try it on a personal project.