3 ms·

Lack of exception handling is the biggest reason I haven't used Go for much. The other reasons are that it's just so plain/boring (yes, I know that's subjective

Lack of exception handling is the biggest reason I haven't used Go for much. The other reasons are that it's just so plain/boring (yes, I know that's subjective), nothing about the syntax is interesting. Learning go is like eating cardboard. The other issues are that IDE support is very primitive and that Java and Scala are both faster and better supported in terms of tooling. Go seems rather nice, just very boring and not very compelling vs. many other tools.

EdiX 14y ago
> Lack of exception handling is the biggest reason I haven't used Go for much. Go does exception handling with panic, recover and its reflection syntax.
- trailfox 14y ago
  So if I'm reading from a file I should use panic recover and not return code checking?? That's not what I've seen in the docs.
  - jlgreco 14y ago
    You seem to be missing the difference between "can you do it" and "should you do it". The reason that you should not is because doing so is not idiomatic Go. You are completely able to do so though.
- NateDad 14y ago
  Using panic and recover is strongly discouraged, and in the rare cases where it makes the code significantly simpler, panics should never cross package boundaries (which is to say, you should never have a public API that can panic, unless you fully expect the panic to take down the process).
  - EdiX 14y ago
    Using panics for control flow or having panics cross library boundaries is strongly discouraged, otherwise they are fine. Go's own standard library uses them internally in several places. Even then discouraging panics is very different from not having them.
NateDad 14y ago
I thought lack of exceptions was a deal killer for me, until I started using Go... and then I realized how much better multiple returns is. You never have to worry about your code suddenly exiting out of the middle of a function if you don't want it to. If something returns an error... it's just a value returned. Hi error! How's it going? In languages with exceptions, potentially any function call you make could throw, and you don't know, because it could be 6 levels deep in the call stack. (Even Java's checked exceptions don't help, since someone down the line inevitably just rights "throws exception" and the screws everyone up the stack). Go is really fast to pick up, it's pleasant to write code in, and yes... it's boring. I think that's it's biggest feature. It gets out of your way so you can produce a product. Why does the language need to be interesting? Isn't it more important that it can build interesting things quickly and reliably? Go does that.
- trailfox 14y ago
  It seems silly to have to check the error return code with an if for every method I call. Surely a try { } catch around a block makes more sense than littering my code with if (errorHappened) in every second line.
  - NateDad 14y ago
    How do you know what failed, then? A try/catch around the entire function simply tells you "something failed". Often times that is not good enough in a real program. You can't handle the error, since you don't know what function call it came from, so you're probably just logging it and swallowing it. It also means that you don't know how much of your code executed. Have you written that file to disk yet? Maybe you need to clean it up now? Is that socket still open? or maybe you didn't get that far in the code? In code that cares about handling errors, you end up with a lot of try/catches around individual functions that you know can throw... this is no different than go's if err != nil code. try { v = ThisCanThrow() } catch (Exception ex) { // handle this specific failure } v, err := ThisCanError() if err != nil { // handle this specific failure } Because Go forces you to handle the error at the site where it is produced, error handling ends up being much more robust and specific. You can't just "let 'em fly" and make someone else deal with random exceptions up the stack. This almost always produces better code in the end. Believe me, I understand where you're coming from. I've been using exceptions for 13 years in production code. I initially skipped Go pretty much solely because of the lack of exceptions. But I am really glad I gave it a second chance, because, damn, it is good.

EdiX 14y ago

> Lack of exception handling is the biggest reason I haven't used Go for much. Go does exception handling with panic, recover and its reflection syntax.

trailfox 14y ago
So if I'm reading from a file I should use panic recover and not return code checking?? That's not what I've seen in the docs.
- jlgreco 14y ago
  You seem to be missing the difference between "can you do it" and "should you do it". The reason that you should not is because doing so is not idiomatic Go. You are completely able to do so though.
NateDad 14y ago
Using panic and recover is strongly discouraged, and in the rare cases where it makes the code significantly simpler, panics should never cross package boundaries (which is to say, you should never have a public API that can panic, unless you fully expect the panic to take down the process).
- EdiX 14y ago
  Using panics for control flow or having panics cross library boundaries is strongly discouraged, otherwise they are fine. Go's own standard library uses them internally in several places. Even then discouraging panics is very different from not having them.

NateDad 14y ago

I thought lack of exceptions was a deal killer for me, until I started using Go... and then I realized how much better multiple returns is. You never have to worry about your code suddenly exiting out of the middle of a function if you don't want it to. If something returns an error... it's just a value returned. Hi error! How's it going? In languages with exceptions, potentially any function call you make could throw, and you don't know, because it could be 6 levels deep in the call stack. (Even Java's checked exceptions don't help, since someone down the line inevitably just rights "throws exception" and the screws everyone up the stack). Go is really fast to pick up, it's pleasant to write code in, and yes... it's boring. I think that's it's biggest feature. It gets out of your way so you can produce a product. Why does the language need to be interesting? Isn't it more important that it can build interesting things quickly and reliably? Go does that.

trailfox 14y ago
It seems silly to have to check the error return code with an if for every method I call. Surely a try { } catch around a block makes more sense than littering my code with if (errorHappened) in every second line.
- NateDad 14y ago
  How do you know what failed, then? A try/catch around the entire function simply tells you "something failed". Often times that is not good enough in a real program. You can't handle the error, since you don't know what function call it came from, so you're probably just logging it and swallowing it. It also means that you don't know how much of your code executed. Have you written that file to disk yet? Maybe you need to clean it up now? Is that socket still open? or maybe you didn't get that far in the code? In code that cares about handling errors, you end up with a lot of try/catches around individual functions that you know can throw... this is no different than go's if err != nil code. try { v = ThisCanThrow() } catch (Exception ex) { // handle this specific failure } v, err := ThisCanError() if err != nil { // handle this specific failure } Because Go forces you to handle the error at the site where it is produced, error handling ends up being much more robust and specific. You can't just "let 'em fly" and make someone else deal with random exceptions up the stack. This almost always produces better code in the end. Believe me, I understand where you're coming from. I've been using exceptions for 13 years in production code. I initially skipped Go pretty much solely because of the lack of exceptions. But I am really glad I gave it a second chance, because, damn, it is good.