5 ms·

> Worse, everything that happens in a try block is 'flattened.' Not only does this mean you may need many try blocks, sometimes it can even be difficult to take

> Worse, everything that happens in a try block is 'flattened.' Not only does this mean you may need many try blocks, sometimes it can even be difficult to take individual statements and put them in one try block. Go has exactly the same issue. But with exceptions at least you can group multiple statements together and handle them with one catch block. With Go you have to use multiple if blocks to get the same semantics. > Go doesn't even really force you to check your errors, it just makes it harder to accidentally not check them. Go doesn't make it harder to accidentally not check errors. If you call a function that only returns an error, such as os.Mkdir(), then the compiler will not warn you when you forget to handle the error. > Language ergonomics are complicated, but the benefits of Go's approach are hard to deny. I don't really see any benefit to Go's approach over exceptions or result types. If making it obvious that errors are handled is important, there's a solution for that that's much more elegant than if-err-nil blocks everywhere. It's precisely the solution that the Go community just rejected.

jchw 7y ago
>Go has exactly the same issue. But with exceptions at least you can group multiple statements together and handle them with one catch block. With Go you have to use multiple if blocks to get the same semantics. Go does not suffer from this issue at all. I am not talking about flattening from the call hierarchy, I am talking about flattening the try scope itself. (In case it isn’t obvious: in Go you’d be forced to separate two error checks. But it results in still less cumbersome code, since you only need scoping for the error handling portions.) But forgetting that, because passing errors down in Go is explicit, it is actually customary to use error wrapping to add context as an error is propagated, which does allow for more precise error handling actually. >Go doesn't make it harder to accidentally not check errors. If you call a function that only returns an error, such as os.Mkdir(), then the compiler will not warn you when you forget to handle the error. Go vet will do that. It is a good 'first step' to configure when setting up your CI/CD (many will do it by default.) Go vet's 'unusedresult' checker does this. >I don't really see any benefit to Go's approach over exceptions or result types. It is a simpler language than Java. You get most of the benefits of checked exceptions without all of the calories from exceptions.
- pcwalton 7y ago
  > But it results in still less cumbersome code, since you only need scoping for the error handling portions.) There isn't a meaningful difference in cumbersomeness between having two try-catch blocks and two if-err blocks. There is a meaningful difference in cumbersomeness between what Go has today and "try foo(try bar())". Which is why it's so unfortunate that the community killed the try proposal. > But forgetting that, because passing errors down in Go is explicit, it is actually customary to use error wrapping to add context as an error is propagated, People say this, but in practice any code search reveals that "if err != nil { return err }" is everywhere. I believe that many Go projects aspire to annotate all errors, but much fewer actually do. Ironically, the nice thing about exceptions, as well as Rust error chaining crates, is that they do this automatically, so in practice programs written in languages with those features tend to have better error diagnostics than Go programs do. Computers are better at doing things consistently than humans are. > It is a simpler language than Java. You get most of the benefits of checked exceptions without all of the calories from exceptions. Go is a more complex language than Java is overall, because of all the special cases the language adds to magic types like maps and errors that are just part of the library in Java.
  - weberc2 7y ago
    I like your points about diagnostics. I definitely feel this—it seems like one of Go’s weakest points. That said, Go is still one of the best tools available for building software today.
  - wybiral 7y ago
    > any code search reveals that "if err != nil { return err }" is everywhere Code searches in languages with exceptions tend to wrap the tryblocks around massive portions of code instead of the individual function calls to the point that you have a top level doing: try: ...program here... except: print('¯\_(ツ)_/¯')
    - KirinDave 7y ago
      ... I could do this with Golang too, couldn't I?

jchw 7y ago

>Go has exactly the same issue. But with exceptions at least you can group multiple statements together and handle them with one catch block. With Go you have to use multiple if blocks to get the same semantics. Go does not suffer from this issue at all. I am not talking about flattening from the call hierarchy, I am talking about flattening the try scope itself. (In case it isn’t obvious: in Go you’d be forced to separate two error checks. But it results in still less cumbersome code, since you only need scoping for the error handling portions.) But forgetting that, because passing errors down in Go is explicit, it is actually customary to use error wrapping to add context as an error is propagated, which does allow for more precise error handling actually. >Go doesn't make it harder to accidentally not check errors. If you call a function that only returns an error, such as os.Mkdir(), then the compiler will not warn you when you forget to handle the error. Go vet will do that. It is a good 'first step' to configure when setting up your CI/CD (many will do it by default.) Go vet's 'unusedresult' checker does this. >I don't really see any benefit to Go's approach over exceptions or result types. It is a simpler language than Java. You get most of the benefits of checked exceptions without all of the calories from exceptions.

pcwalton 7y ago
> But it results in still less cumbersome code, since you only need scoping for the error handling portions.) There isn't a meaningful difference in cumbersomeness between having two try-catch blocks and two if-err blocks. There is a meaningful difference in cumbersomeness between what Go has today and "try foo(try bar())". Which is why it's so unfortunate that the community killed the try proposal. > But forgetting that, because passing errors down in Go is explicit, it is actually customary to use error wrapping to add context as an error is propagated, People say this, but in practice any code search reveals that "if err != nil { return err }" is everywhere. I believe that many Go projects aspire to annotate all errors, but much fewer actually do. Ironically, the nice thing about exceptions, as well as Rust error chaining crates, is that they do this automatically, so in practice programs written in languages with those features tend to have better error diagnostics than Go programs do. Computers are better at doing things consistently than humans are. > It is a simpler language than Java. You get most of the benefits of checked exceptions without all of the calories from exceptions. Go is a more complex language than Java is overall, because of all the special cases the language adds to magic types like maps and errors that are just part of the library in Java.
- weberc2 7y ago
  I like your points about diagnostics. I definitely feel this—it seems like one of Go’s weakest points. That said, Go is still one of the best tools available for building software today.
- wybiral 7y ago
  > any code search reveals that "if err != nil { return err }" is everywhere Code searches in languages with exceptions tend to wrap the tryblocks around massive portions of code instead of the individual function calls to the point that you have a top level doing: try: ...program here... except: print('¯\_(ツ)_/¯')
  - KirinDave 7y ago
    ... I could do this with Golang too, couldn't I?