5 ms·

> I ended up thinking about every possible error. Exactly. In Go you can't just wrap code in a try/catch block and not deal with the fall out. You can ignore e

> I ended up thinking about every possible error. Exactly. In Go you can't just wrap code in a try/catch block and not deal with the fall out. You can ignore errors with _, but you still have to explicitly write out _, so you visually see what you're ignoring. I think this is Go's simplicity is actually helpful. It feels like boilerplate at first, but there is something to being _forced_ to handle edge cases sooner rather than later.

twblalock 11y ago
It's not just the try/catch thing. Ruby code can have a syntax error in a conditional that is rarely true, which may crop up in production from time to time. I've seen it happen many times, including in some popular Ruby libraries. A compiled language would have caught that.
- deleted 11y ago
  [deleted]
- 0x0dea 11y ago
  "Ruby code can have a syntax error in a conditional..." No, it can't. If this is something you've seen "many times", would you mind providing an example? Show me a program that Ruby tries to execute without having been able to parse it.
  - TheDong 11y ago
    if foo.something foo.instance_eval "SYNTAX ERROR" end I know any form of eval is sort of cheating... But perhaps what he meant was not a syntax error, but things like: if foo.something foo.something_misspelled = bar end Which isn't technically a syntax error, but that code is invalid in a statically typed language.
- dkubb 11y ago
  Did you mean to say "semantic error" instead of "syntax error"?
TheDong 11y ago
No, you don't need the 'try / catch' syntax, but in Go you can ignore errors. And instead of 'try / catch', you have the frustrating 'if err != nil { return nil, nil }'. io.Copy(out, in) Did you know io.Copy returns an error? It does, and I rarely see it handled. You don't need to explicitly '_' ignore things. If you're about to say 'errcheck', well, great, it's not built into the language and what matters is practice; large go codebases do not use errcheck typically. Also, errcheck only handles things that fill the error interface, which e.g. the 'bool ok' return values (such as from map accesses) do not. With Java exceptions, at least, you must explicitly handle an exception in some way. If you don't try/catch it, you have to add the throws declaration to your method. You have to handle that case. Furthermore, you know exactly what sort of error it is. In Go, you get the silly "error" interface. So it's something. Have fun figuring out how to handle it. It's not like the language encourages you to just return 'errors.New/fmt.Errorf' so there's actually no way short of complicated regex string matches to figure out what error case you're actually handling. You don't get given all possible types of the error, if you try to switch on err == io.EOF or err == io.UnexpectedEOF or so on, how will you know that you got them all? The compiler sure as hell won't tell you. With exceptions, you typically do have to get them all, you do have to account for all the types (and if you add a new type further down the stack, you'll have to make sure you handled it correctly further up). You can just catch 'Exception' and be in a similar place to Go, but at least Exceptions give you the option to do things more right. Your point makes utterly no sense to me. Between Go 'errors' and Java 'Exceptions', only exceptions a) Make you actually think about and handle every one of them b) Can give you information about all possible types it may have and c) allow you to elegantly let a parent function handle it without 3 lines of utterly boilerplate code after every single function call. Sometimes I think that Gophers just want to feel like they're handling errors. so they love 10% of their code being utterly worthless while not actually having any common way to handle specific error types and while managing to make worse error handling then every single other modern language, and then be proud of it.
- wiremine 11y ago
  > Did you know io.Copy returns an error? It does, and I rarely see it handled. You don't need to explicitly '_' ignore things. Correct, and I agree this isn't explicit. I'd actually like to see you _not_ be able to ignore errors like this. But that's just me maybe. > Your point makes utterly no sense to me. My point is Go, by it's simplistic nature, more often than not forces you to at least think about the error case, instead of punting it to another part of the code. This is the point of the parent comment which I'm in agreement with. If you're writing 'if err != nil { return nil, nil}' you're failing on oh so many levels. Also, Java doesn't make you think about handling exceptions any more than Go does. If we're talking about code, I've seen lots of Java where the programmer figured "oh, I'll let someone else handle these exceptions..."

twblalock 11y ago

It's not just the try/catch thing. Ruby code can have a syntax error in a conditional that is rarely true, which may crop up in production from time to time. I've seen it happen many times, including in some popular Ruby libraries. A compiled language would have caught that.

deleted 11y ago
[deleted]
0x0dea 11y ago
"Ruby code can have a syntax error in a conditional..." No, it can't. If this is something you've seen "many times", would you mind providing an example? Show me a program that Ruby tries to execute without having been able to parse it.
- TheDong 11y ago
  if foo.something foo.instance_eval "SYNTAX ERROR" end I know any form of eval is sort of cheating... But perhaps what he meant was not a syntax error, but things like: if foo.something foo.something_misspelled = bar end Which isn't technically a syntax error, but that code is invalid in a statically typed language.
dkubb 11y ago
Did you mean to say "semantic error" instead of "syntax error"?

TheDong 11y ago

No, you don't need the 'try / catch' syntax, but in Go you can ignore errors. And instead of 'try / catch', you have the frustrating 'if err != nil { return nil, nil }'. io.Copy(out, in) Did you know io.Copy returns an error? It does, and I rarely see it handled. You don't need to explicitly '_' ignore things. If you're about to say 'errcheck', well, great, it's not built into the language and what matters is practice; large go codebases do not use errcheck typically. Also, errcheck only handles things that fill the error interface, which e.g. the 'bool ok' return values (such as from map accesses) do not. With Java exceptions, at least, you must explicitly handle an exception in some way. If you don't try/catch it, you have to add the throws declaration to your method. You have to handle that case. Furthermore, you know exactly what sort of error it is. In Go, you get the silly "error" interface. So it's something. Have fun figuring out how to handle it. It's not like the language encourages you to just return 'errors.New/fmt.Errorf' so there's actually no way short of complicated regex string matches to figure out what error case you're actually handling. You don't get given all possible types of the error, if you try to switch on err == io.EOF or err == io.UnexpectedEOF or so on, how will you know that you got them all? The compiler sure as hell won't tell you. With exceptions, you typically do have to get them all, you do have to account for all the types (and if you add a new type further down the stack, you'll have to make sure you handled it correctly further up). You can just catch 'Exception' and be in a similar place to Go, but at least Exceptions give you the option to do things more right. Your point makes utterly no sense to me. Between Go 'errors' and Java 'Exceptions', only exceptions a) Make you actually think about and handle every one of them b) Can give you information about all possible types it may have and c) allow you to elegantly let a parent function handle it without 3 lines of utterly boilerplate code after every single function call. Sometimes I think that Gophers just want to feel like they're handling errors. so they love 10% of their code being utterly worthless while not actually having any common way to handle specific error types and while managing to make worse error handling then every single other modern language, and then be proud of it.

wiremine 11y ago
> Did you know io.Copy returns an error? It does, and I rarely see it handled. You don't need to explicitly '_' ignore things. Correct, and I agree this isn't explicit. I'd actually like to see you _not_ be able to ignore errors like this. But that's just me maybe. > Your point makes utterly no sense to me. My point is Go, by it's simplistic nature, more often than not forces you to at least think about the error case, instead of punting it to another part of the code. This is the point of the parent comment which I'm in agreement with. If you're writing 'if err != nil { return nil, nil}' you're failing on oh so many levels. Also, Java doesn't make you think about handling exceptions any more than Go does. If we're talking about code, I've seen lots of Java where the programmer figured "oh, I'll let someone else handle these exceptions..."