3 ms·

Other than the fact that they spelled "throw" "panic", "catch" "recover", and "finally" "defer" how are go exceptions different than what you find in java? I g

• eweise 3y ago
  Not sure why people downvote instead of answering the question.
  • randomdata 3y ago
    The comment answers its own question. As to why press a button that does nothing? For the same reason fidget spinners were all the rage a few years back: Bored people like to do something with their hands. Perhaps if the comment had a question that was left unanswered, people wouldn't have become so bored?
    • eweise 3y ago
      "how are go exceptions different than what you find in java?" They are not the same. Thought someone might be helpful and list the differences.
      • randomdata 3y ago
        Why not lead by example?
        • eweise 3y ago
          Already been done by other posters in the thread so you can stop your snarky comments.
          • randomdata 3y ago
            Not really. The only suggested difference is that you "need to do something special to get a stack trace out" in Go, but that one is not even true. There is nothing special needed to get the stack trace. I suspect he is confusing exceptions with errors, the latter of which have no need for stack traces in the general case, so you would need to do something special to include the stack trace in an error for your special case. There is more content in the thread, but not about exceptions. So, with that, here's your time to shine!
            • eweise 3y ago
              Sorry but I'm not your monkey. Go troll someone else.
              • randomdata 3y ago
                Then how do you explain the monkey behaviour you have given me?
                • eweise 3y ago
                  grow up little boy.
• tubthumper8 3y ago
  Disclaimer: just trying to directly answer the question, but also may be wrong in many ways. Please correct me. I thought one difference was that a panic in a goroutine kills the whole process vs. an exception in a Java thread would just kill that thread. That could be more of a consequence of "Goroutines are not threads" rather than "panics are not exceptions". Java Checked exceptions are certainly quite different than Go panics in terms of compile-time checks and what code the user of the language must write. I thought there are some differences with how stack traces are accessed on caught/recovered exceptions? It's been a while now but I thought you needed something special to get the Go stack trace out. Fairly minor detail though. Error is an interface in Go vs. a base class that's extended. Probably more of a result of other language design decisions rather than a decision in this particular area. I haven't really seen the catch-and-rethrow paradigm for Go panics, but it's kinda different because `panic` only accepts a string argument whereas you can rethrow an "object" in Java (side note - sometimes Go error handling ends up having a lot of string concatenation ex. errors.Wrap because of the focus on "errors are strings"). The lack of catch-and-rethrow is more of a usage difference than a design difference, to your main point. Probably others but can't think of them right now.
  • knorker 3y ago
    > I thought one difference was that a panic in a goroutine kills the whole process Only if not caught. But in any case this still means that you need to write exception safe code, because you don't know if the function you call will throw, and you don't know if the function calling you will catch. > `panic` only accepts a string argument No: https://go.dev/play/p/ZDKpybtxABL https://go.dev/play/p/ZDKpybtxABL > catch-and-rethrow paradigm for Go panics Probably because "you're not supposed to". You can.
    • tubthumper8 3y ago
      Thanks for the clarification on the panic function signature - I missed it when checking the spec but it's definitely in there and defined as taking `interface{}` https://go.dev/ref/spec#Handling_panics https://go.dev/ref/spec#Handling_panics
  • 3y ago