6 ms·

> Insisting that the language doesn't have exceptions Insist in what way? The Go website insists that Go has actual exceptions, unlike the pretend exceptions t

• lokar 3y ago
  So many people confuse errors with exceptions
  • groestl 3y ago
    Errors are just checked exceptions where you get the chance to introduce bugs, by unrolling the stack manually.
    • randomdata 3y ago
      Errors are things that can fail after the program is written (hard drive crash, network failure, etc.). Exceptions are things that were already broken when you wrote the code (null pointer access, index out of bounds, etc.) To put it another way, exceptions are failures that a sufficiently smart compiler would have been able to catch at compile time. Of course, creating a compiler that smart is a monumental task, so we accept catching some programmer mistakes at runtime as a reasonable tradeoff.
      • groestl 3y ago
        > exceptions are failures that a sufficiently smart compiler would have been able to catch at compile time Would love to see your proof of this for stack overflow exceptions. You could become very famous.
        • randomdata 3y ago
          If you are trying to suggest that the stack is runtime unpredictable like a hard drive, overflowing it would be an error, not an exception. Therefore, a sufficiently smart compiler just needs to ensure that you have done the proper accounting of stack use and handle the error condition if you are approaching an overflow state. With that, you can prevent it becoming an exception. If you encounter a stack overflow exception, it is because you didn't do your due diligence. Technically your program is flawed. Granted, the pragmatic engineer probably doesn't care about correctness in that area. It turns out not all programs have to be perfect to be useful. No fame for me, I'm afraid. There is nothing here out of the ordinary.
• monocasa 3y ago
  Given how they being up how fmt and http swallow them, I believe the parent is referring to panics rather the errors returned via standard control flow.
  • randomdata 3y ago
    Yes, that's what we're talking about (exceptions, or panics if that's what you want to call them). That's what exceptions are.
    • monocasa 3y ago
      I guess I'm confused since panics are equally errors passed around by gotos as much as java exceptions are. Probably more so since at least with java it ends up being part of the the function type signature the vast majority of the time.
      • everforward 3y ago
        It creates 2 disparate types of error handling that don't neatly mesh together. You have to handle error return values, but you also have to handle exceptions (panics) because they still exist. My issue is mostly implementing both ways of bubbling up an error to somewhere it can be handled. I think having either error return values or exceptions is preferable to having both. I don't think exceptions are perfect, but if panic() absolutely has to exist then I'd rather have an entirely exception-based language than a language that uses both systems simultaneously. E.g. if I write a function that accesses an element of an array without bounds-checking, it could panic and I have to handle that exception. Bounds-checking basically just becomes finding things that would throw exceptions and converting them to errors so we can pretend that exceptions don't exist.
        • randomdata 3y ago
          > It creates 2 disparate types of error handling They are disparate conditions. Errors happen in response to conditions that occur during the execution of the application. Exceptions happen in response to conditions that occurred when the code was written. Very different things. It is highly unlikely that you want to handle an exception. It's the runtime equivalent of a compiler error. Do you also want to handle compiler errors so that your faulty code still compiles? Of course not, so why would you want to do the same when your coding mistakes are noticed at runtime? There are, uh, exceptions to that when it is necessary to handle exceptions, but if it you see it as routine you're doing something wrong. If you overloaded that with errors, forcing it to be routine, you'd have a nightmare on your hands (like in those other languages that have tried it).
• stonemetal12 3y ago
  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 get that Go devs like to claim they are completely different because you are supposed to use them differently, but under the hood they are identical as far as I can tell.
  • 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
• knorker 3y ago
  Not sure what your question is. "Insist in what way": starts with things like the Go FAQ having a question called "Why does Go not have exceptions?". The answer does elaborate, so it's not like they're lying, exactly. But anything and everything Go says about this also applies to C++. There's no relevant technical difference between Go and C++ exceptions, nor is there a difference in how the standard library uses them. ... except the Go standard library swallows exceptions in some cases, which is like the biggest no-no you can do. But nobody would say that C++ doesn't have exceptions.
  • randomdata 3y ago
    Go clearly has exceptions. It always has. Thus I ask what is being insisted. Like, specifically. Is it being insisted in some tangential way, like 'Go doesn't have "try", "catch", and "finally" keywords'? Something like that would be true. Or is the insistence straight up "Go does not have exceptions!"? If that is the case, who is saying it? Did you just read it in one of the regularly scheduled Rust advertisements that get posted here? Or did it come from someone who actually means something in the Go community?
    • knorker 3y ago
      Like specifically what I just mentioned: the official FAQ. And repeatedly from Pike, core documentation, and other core developers.
      • randomdata 3y ago
        Huh? There is nothing in the FAQ claiming that Go doesn't have exceptions... It literally says that Go does have exceptions. Are you referring to the frequently asked question itself? That's the only thing in there that could even possibly make you think Go doesn't have exceptions. Except, being a FAQ, you know that the question comes externally from people who don't know about Go. That is why they are asking the Go people the question! One would have to be braindead to think that is an insistence. Maybe you need to be even more specific.