4 ms·

> all I see error handling do is just print the error and then return. Yeah, that is a problem. At least they had to manually type it out and (maybe) think abo

> all I see error handling do is just print the error and then return. Yeah, that is a problem. At least they had to manually type it out and (maybe) think about how to handle the error during that time. To streamline this is to further exacerbate the issue. They will do a try/catch try/defer `log.Println`. With Python try/catch allows for ultimate laziness. It allows for 1,000 line try/catch blocks that can hide/capture errors that bubble up from anywhere. Of course this is bad development but it's possible. Currently with Go it is impossible to forget about error handling. You have to consciously make a choice on what to do with it. Even if that choice is to log/print it out.

lgunsch 7y ago
I once code-reviewed a serious bug-fix, in Python, causing leaking threads to crash a server. The bug turned out to be a bare try-except hiding a function call with a missing argument; 2 args passed instead of 3. Not exactly a syntax error, but pretty close.
dec0dedab0de 7y ago
Many times I've had to say NO DONT DO THAT! to people writing giant try/except blocks in Python. Usually the answer is to wait for an actual exception and if it's not something you could actually anticipate, then write a tiny try block that just handles the exception. The whole point being that I want it to fail if there is an unknown exception. Which in Go, you wont fail at runtime if you are just printing errors as a habit( I think, I have not done much with go). That said, a lot of times it makes sense to return errors, and perhaps there in lies the difference between an exception and an error.
- superbaconman 7y ago
  Massive try catch statements introduce excessive indentation, and moves the handling logic away from what's being handled. It's hard to believe that this would be common practice among anyone with a few years under the belt.
msbarnett 7y ago
> Currently with Go it is impossible to forget about error handling. You’re describing some other language that forces you to deal with errors, like Haskell or Rust. A bare io.WriteString(w, “ok”) will happily compile despite returning a completely unhandled error.
- xmprt 7y ago
  Meanwhile code like a, b := someFunc() fmt.Println(b) throws a compiler error like it's the end of the world if you define a variable that isn't used.
  - pstuart 7y ago
    If you can type "a, b :=", you can type "_, b :=". It's not a big deal.
    - saghm 7y ago
      When I wrote Go at work, this would mostly be annoying when interactively writing and running code; if I want to comment out the only line below that uses `a` and run it again, now I have to go back and change the declaration also. Once I want to to run that line again, I can't just uncomment it; I have to go back and declare it again. I would have to do stuff like this fairly often when trying to debug failed tests, so despite the fact that I'd never want to _commit_ code with an unused variable, I certainly would like to be able to _run_ it when debugging. I feel like a warning is definitely better than a hard error here; it's pretty easy in most languages with warnings to set up CI to reject unused variables, which ensures that your code in production won't have any unused variables.
      - pstuart 7y ago
        Understood. I think the problem is that once options like that are given they become abused and eventually institutionalized. A quick work around for that example would be to a line: `b = b`. Go vet complains but it builds and runs.
crimsonalucard 7y ago
the Golang way breaks function composition to make error handling a bit more explicit. There are actually better ways. Rust and Haskell not only fix this problem without breaking function composition... they make it so that the compiler is able to catch missing error handling logic. The golang way of doing this is not the ideal way, but it does fix your issue with python.
apta 7y ago
> Currently with Go it is impossible to forget about error handling. Not true at all. The easiest example is: func main() { fmt.Println("") } The error is not being handled. An exception-based language doesn't have this issue, neither does a language that actually forces you to handle errors.

lgunsch 7y ago

I once code-reviewed a serious bug-fix, in Python, causing leaking threads to crash a server. The bug turned out to be a bare try-except hiding a function call with a missing argument; 2 args passed instead of 3. Not exactly a syntax error, but pretty close.

dec0dedab0de 7y ago

Many times I've had to say NO DONT DO THAT! to people writing giant try/except blocks in Python. Usually the answer is to wait for an actual exception and if it's not something you could actually anticipate, then write a tiny try block that just handles the exception. The whole point being that I want it to fail if there is an unknown exception. Which in Go, you wont fail at runtime if you are just printing errors as a habit( I think, I have not done much with go). That said, a lot of times it makes sense to return errors, and perhaps there in lies the difference between an exception and an error.

superbaconman 7y ago
Massive try catch statements introduce excessive indentation, and moves the handling logic away from what's being handled. It's hard to believe that this would be common practice among anyone with a few years under the belt.

msbarnett 7y ago

> Currently with Go it is impossible to forget about error handling. You’re describing some other language that forces you to deal with errors, like Haskell or Rust. A bare io.WriteString(w, “ok”) will happily compile despite returning a completely unhandled error.

xmprt 7y ago
Meanwhile code like a, b := someFunc() fmt.Println(b) throws a compiler error like it's the end of the world if you define a variable that isn't used.
- pstuart 7y ago
  If you can type "a, b :=", you can type "_, b :=". It's not a big deal.
  - saghm 7y ago
    When I wrote Go at work, this would mostly be annoying when interactively writing and running code; if I want to comment out the only line below that uses `a` and run it again, now I have to go back and change the declaration also. Once I want to to run that line again, I can't just uncomment it; I have to go back and declare it again. I would have to do stuff like this fairly often when trying to debug failed tests, so despite the fact that I'd never want to _commit_ code with an unused variable, I certainly would like to be able to _run_ it when debugging. I feel like a warning is definitely better than a hard error here; it's pretty easy in most languages with warnings to set up CI to reject unused variables, which ensures that your code in production won't have any unused variables.
    - pstuart 7y ago
      Understood. I think the problem is that once options like that are given they become abused and eventually institutionalized. A quick work around for that example would be to a line: `b = b`. Go vet complains but it builds and runs.

crimsonalucard 7y ago

the Golang way breaks function composition to make error handling a bit more explicit. There are actually better ways. Rust and Haskell not only fix this problem without breaking function composition... they make it so that the compiler is able to catch missing error handling logic. The golang way of doing this is not the ideal way, but it does fix your issue with python.

apta 7y ago

> Currently with Go it is impossible to forget about error handling. Not true at all. The easiest example is: func main() { fmt.Println("") } The error is not being handled. An exception-based language doesn't have this issue, neither does a language that actually forces you to handle errors.