5 ms·

>especially when the code seems to continue after printing the error (making it a bug, by reporting a warning as an error). Maybe I'm misunderstanding somethin

>especially when the code seems to continue after printing the error (making it a bug, by reporting a warning as an error). Maybe I'm misunderstanding something, but if you call a function and it returns an error, it's your responsibility to ensure that you handle it. Generally you'd assume any data returned by the same call that returned the error is useless (except stuff like EOF, in some cases?).

erikb 9y ago
Yes, exactly. That's what one would assume. I don't understand why a whole language community decided to not handle any errors and instead just bubble them up without filtering, without adding more notifications about the context like log messages, without trying to recover. Why would they expect a user to know their whole dependency tree and all their error messages.
- _ph_ 9y ago
  I am not aware that they did. Most good Go code does not do this. That there exist some badly written Go programs does not contradict this. Go functions that can fail, should return an error as part of the function returns. Like with exceptions, you can decide to ignore any error or properly handle it. Even with checked exceptions, you can have an empty "catch", which means you are just ignoring it. So the difference is rather syntactical. And like with exceptions, proper error handling is entirely the responsibility of the programmer who writes the error handling code. The Go version of error handling requires less typing overall, and makes it a little bit easier to ignore errors. Unhanded exceptions on the other side can unwind the stack arbitrarily high up until they do eventually find a handler - but it is not said, that this handler can properly handle the exception, as it might be separated to far from the error source.
  - vram22 9y ago
    >The Go version of error handling requires less typing overall Do you mean as compared to using exceptions in a language like Python or Java? If so, can you give an example of code that does the same task, in both types of languages, to make this more clear? Thanks.
    - _ph_ 9y ago
      I was mostly thinking of Java. Ignoring an exception would be done with try {....} catch (Exception e) {}, while in Go, you would do: x,_ := f(...). And if you want to check a returned error I think the if err!=nil {...} is still a bit less typing than the Java version, and you don't have to declare checked exceptions you might throw.
      - vram22 9y ago
        Got it now.
      - concede_pluto 9y ago
        In Go, if you call three functions you need to repeat the x, err := do_something() if err != nil { return nil, err } ceremony three times. In Java it happens by default, because the language designers agreed this is by far the most common case. Ignoring an error is almost always a serious mistake, so the fact that Go makes it easy and not blatant is not a good thing.
        vram22 9y ago
        >ceremony three times. In Java it happens by default, What happens by default? Not clear. (I know Java, but not up to date with recent versions.) >Ignoring an error is almost always a serious mistake Agreed.
        concede_pluto 9y ago
        In Java, an exception outside a catch block automatically stops the method and raises the exception to the caller, and then their caller, and so on. In Go you have to write this after every function call (except the tiny minority that can only panic).
        vram22 9y ago
        Thanks. I did know that about Java (having used it), just that it was not clear to me from your earlier wording, that that is what you were saying. NP.
  - erikb 9y ago
    As far as I know bubbling up errors instead of handling them is recommended practice: https://github.com/nats-io/go-nats-streaming/issues/143#issuecomment-312810459 https://github.com/nats-io/go-nats-streaming/issues/143#issu...
- glic3rinu 9y ago
  Google C++ style guide states that you should not use exceptions https://google.github.io/styleguide/cppguide.html#Exceptions https://google.github.io/styleguide/cppguide.html#Exceptions golang was probably designed by people following those same guidelines ...

erikb 9y ago

Yes, exactly. That's what one would assume. I don't understand why a whole language community decided to not handle any errors and instead just bubble them up without filtering, without adding more notifications about the context like log messages, without trying to recover. Why would they expect a user to know their whole dependency tree and all their error messages.

_ph_ 9y ago
I am not aware that they did. Most good Go code does not do this. That there exist some badly written Go programs does not contradict this. Go functions that can fail, should return an error as part of the function returns. Like with exceptions, you can decide to ignore any error or properly handle it. Even with checked exceptions, you can have an empty "catch", which means you are just ignoring it. So the difference is rather syntactical. And like with exceptions, proper error handling is entirely the responsibility of the programmer who writes the error handling code. The Go version of error handling requires less typing overall, and makes it a little bit easier to ignore errors. Unhanded exceptions on the other side can unwind the stack arbitrarily high up until they do eventually find a handler - but it is not said, that this handler can properly handle the exception, as it might be separated to far from the error source.
- vram22 9y ago
  >The Go version of error handling requires less typing overall Do you mean as compared to using exceptions in a language like Python or Java? If so, can you give an example of code that does the same task, in both types of languages, to make this more clear? Thanks.
  - _ph_ 9y ago
    I was mostly thinking of Java. Ignoring an exception would be done with try {....} catch (Exception e) {}, while in Go, you would do: x,_ := f(...). And if you want to check a returned error I think the if err!=nil {...} is still a bit less typing than the Java version, and you don't have to declare checked exceptions you might throw.
    - vram22 9y ago
      Got it now.
    - concede_pluto 9y ago
      In Go, if you call three functions you need to repeat the x, err := do_something() if err != nil { return nil, err } ceremony three times. In Java it happens by default, because the language designers agreed this is by far the most common case. Ignoring an error is almost always a serious mistake, so the fact that Go makes it easy and not blatant is not a good thing.
      - vram22 9y ago
        >ceremony three times. In Java it happens by default, What happens by default? Not clear. (I know Java, but not up to date with recent versions.) >Ignoring an error is almost always a serious mistake Agreed.
        concede_pluto 9y ago
        In Java, an exception outside a catch block automatically stops the method and raises the exception to the caller, and then their caller, and so on. In Go you have to write this after every function call (except the tiny minority that can only panic).
        vram22 9y ago
        Thanks. I did know that about Java (having used it), just that it was not clear to me from your earlier wording, that that is what you were saying. NP.
- erikb 9y ago
  As far as I know bubbling up errors instead of handling them is recommended practice: https://github.com/nats-io/go-nats-streaming/issues/143#issuecomment-312810459 https://github.com/nats-io/go-nats-streaming/issues/143#issu...
glic3rinu 9y ago
Google C++ style guide states that you should not use exceptions https://google.github.io/styleguide/cppguide.html#Exceptions https://google.github.io/styleguide/cppguide.html#Exceptions golang was probably designed by people following those same guidelines ...