3 ms·

OTOH, if you follow Go's idioms and handle every error where it happens, your code will look like having a lot of boilerplate at first, but you end up with bett

OTOH, if you follow Go's idioms and handle every error where it happens, your code will look like having a lot of boilerplate at first, but you end up with better error handling. It's the same as putting a try-except catchall around every single call in python, because in python you can never be sure (without reading the source) what kind of exceptions something will throw. For request based services and something where some big ass operation will either fail in some way (and i don't care where exactly) or be successful, exceptions are fine. If something goes wrong somewhere, log it and reply with HTTP 500. But for servers with data i care about, i most likely want to recover right where the error happened, and actively decide if i want to abort and push the error to the next layer. Not having exceptions makes this more intuitive.

pekk 12y ago
You shouldn't be putting a try-except catchall around every single call in Python. Exceptions mean you don't have to do that.
- moreentropy 12y ago
  For me the most important thing exceptions mean is that they might pop up at any time, with unpredictable types. So as long as I don't have a catch all exception handler wrapped around all code, it might crash at some point.
  - TheLoneWolfling 12y ago
    Assuming you're talking about unchecked exceptions, correct.
    - moreentropy 12y ago
      Python doesn't have checked exceptions.
  - moreentropy 12y ago
    This one really deserved downvoting, great job whoever did that :/
bsdetector 12y ago
> if you ... handle every error where it happens This is what the debate is about: "if". The problem with Go's error handling is that people don't handle every error. And due to poor documentation structure and returning one error type, often you have to even go digging through source code to just find out what the specific error values can be and under what conditions they occur, which makes it easy to write code that you think handles all error conditions but in fact does not. The code on the golang web site didn't even check the error code from println and you never see this done in code. If you point this out you're met with "why would you want to check that error?", which is a tacit admission that Go programs will always have missing error handling and that "if" in "if you handle every error" is never met in reality. In contrast to this there are no Java programs that don't IOException from a failed println, and yes even println can matter. Redirecting output with ">&-" is different from ">/dev/null".

pekk 12y ago

You shouldn't be putting a try-except catchall around every single call in Python. Exceptions mean you don't have to do that.

moreentropy 12y ago
For me the most important thing exceptions mean is that they might pop up at any time, with unpredictable types. So as long as I don't have a catch all exception handler wrapped around all code, it might crash at some point.
- TheLoneWolfling 12y ago
  Assuming you're talking about unchecked exceptions, correct.
  - moreentropy 12y ago
    Python doesn't have checked exceptions.
- moreentropy 12y ago
  This one really deserved downvoting, great job whoever did that :/

bsdetector 12y ago

> if you ... handle every error where it happens This is what the debate is about: "if". The problem with Go's error handling is that people don't handle every error. And due to poor documentation structure and returning one error type, often you have to even go digging through source code to just find out what the specific error values can be and under what conditions they occur, which makes it easy to write code that you think handles all error conditions but in fact does not. The code on the golang web site didn't even check the error code from println and you never see this done in code. If you point this out you're met with "why would you want to check that error?", which is a tacit admission that Go programs will always have missing error handling and that "if" in "if you handle every error" is never met in reality. In contrast to this there are no Java programs that don't IOException from a failed println, and yes even println can matter. Redirecting output with ">&-" is different from ">/dev/null".