4 ms·

Go has no exceptions. Instead, functions can return multiple values, one of which is an error, and you check the error value on invocation. It's tedious and a

by zemo 14y ago

Go has no exceptions. Instead, functions can return multiple values, one of which is an error, and you check the error value on invocation. It's tedious and awful and makes your code very ugly and it's absolutely correct and I love it. It takes some getting used to, but once you do it for a while, you realize that exception handling systems are broken and unnecessary. E.g.: func MaybeAnInt() (int, error) { if FAIL { return 0, errors.New("this is the error message") } return 42, nil } x, err := MaybeAnInt() if err != nil { // handle your error } // normal shit here.

tomjen3 14y ago
That is the best argument against GO I have ever seen. You now have to mix up your exception code and your normal code (or, as I suspect most people will do, ignore the error return value). Did they kill stack traces too?
- dscrd 14y ago
  You cannot ignore the error return value in Go. If you would think a bit more broadly, you might also see this so that all the error handling code is visible, explicit and right there with the actual logic, and not hidden away what might be (and often is) multiple layers of modules.
  - zemo 14y ago
    >You cannot ignore the error return value in Go. that's not true. You can ignore the second parameter by explicitly naming it with an underscore, like this: x, _ := MightFail()
    - dscrd 14y ago
      Well ok, you can explicitly ignore them, but not by being negligent.
- zemo 14y ago
  it sounds bad in theory, but in practice it turns out to be quite good. It's actually the opposite; because you know that there's no exceptions, control flow is very obvious. Whether a function does or does not return an error is a part of its signature. You always know, when calling a function, if it may or may not return an error, and it is up to the caller to decide what to do with that error. As a result, there's no control flow pitfalls like forgetting to close a filehandle because an exception was thrown in some function that you didn't know could throw an exception. >Did they kill stack traces too? no, we have stack traces. Also, it's Go, not GO.
je42 14y ago
that does not scale. you can have hundreds of calls that require error handling inside your code. considering your example you would get the section "//handle you error" hundreds of times. sprinkled all over the place.

by zemo 14y ago

tomjen3 14y ago

That is the best argument against GO I have ever seen. You now have to mix up your exception code and your normal code (or, as I suspect most people will do, ignore the error return value). Did they kill stack traces too?

dscrd 14y ago
You cannot ignore the error return value in Go. If you would think a bit more broadly, you might also see this so that all the error handling code is visible, explicit and right there with the actual logic, and not hidden away what might be (and often is) multiple layers of modules.
- zemo 14y ago
  >You cannot ignore the error return value in Go. that's not true. You can ignore the second parameter by explicitly naming it with an underscore, like this: x, _ := MightFail()
  - dscrd 14y ago
    Well ok, you can explicitly ignore them, but not by being negligent.
zemo 14y ago
it sounds bad in theory, but in practice it turns out to be quite good. It's actually the opposite; because you know that there's no exceptions, control flow is very obvious. Whether a function does or does not return an error is a part of its signature. You always know, when calling a function, if it may or may not return an error, and it is up to the caller to decide what to do with that error. As a result, there's no control flow pitfalls like forgetting to close a filehandle because an exception was thrown in some function that you didn't know could throw an exception. >Did they kill stack traces too? no, we have stack traces. Also, it's Go, not GO.

je42 14y ago

that does not scale. you can have hundreds of calls that require error handling inside your code. considering your example you would get the section "//handle you error" hundreds of times. sprinkled all over the place.