[erikb]

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_]

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.

[erikb]

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#issu...

[vram22]

>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_]

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.

[concede_pluto]

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.

[_ph_]

Yes, I certainly was not advocating ignoring any error. Which is, why exceptions are of dubious use. If you only check exceptions around a larger block of function calls, or every several levels of the call stack, then you might miss the exact source of the exception, unless the exception type is unambiguous. That is, why I find the Go version tedious for sure, but still better than to wrap single function calls into try... catch.

[vram22]

>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]

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]

Got it now.

[glic3rinu]

Google C++ style guide states that you should not use exceptions https://google.github.io/styleguide/cppguide.html#Exceptions golang was probably designed by people following those same guidelines ...