6 ms·
In the language maybe but both Rust and Zig show that it's possible to have much less 'bloat' for error handling even without using exceptions. I'd say that go
by renox 7y ago
In the language maybe but both Rust and Zig show that it's possible to have much less 'bloat' for error handling even without using exceptions.
I'd say that go designers have still work to do: Zig especially show that you can be a 'simple' language and yet have both sane error handling and generics.
- arendtio 7y agoIf someone else is looking for examples too, I found those: https://www.reddit.com/r/Zig/comments/99zlc9/exceptions_or_errors/ https://www.reddit.com/r/Zig/comments/99zlc9/exceptions_or_e...
- DelightOne 7y agoOn the error branch, how do you do code coverage?
- marcus_holmes 7y agoI thought all of this until I got used to Go's error handling. There's a couple aspects to this: 1. After a while, the "if err != nil {" becomes a single statement in your mind, and you only notice it if it's different (like trapping things that should error with "if err == nil {"). In other words, it only feels verbose if you're not used to it. After a while, the regular rhythm of "statement, error check, statement, error check" becomes the routine pattern of your code and it looks weird if you don't check for errors (which is as it should be). 2. The point of Go's error handling is that it isn't magic. There's nothing special about error values, and they are handled exactly the same way as every other variable in the system. The only thing the language defines about errors is that they have a method called Error that returns a string. That's it. This means that you can create complex error handlers if you need it, entirely within the standard language. This is extremely powerful. The Go team's examination of the language error handling is interesting because it seems there's a conflict between newer Gophers who don't like the verbosity of it (but don't realise the power it brings) and the older Gophers who are used to the verbosity and appreciate the power. Almost exactly like TFA. The repitition looks ugly if you don't appreciate the reasons for it.
- edflsafoiewq 7y ago> The point of Go's error handling is that it isn't magic. There's nothing special about error values, and they are handled exactly the same way as every other variable in the system The error maybe, but not the result of the call. The multiple-value return x, err is not a first-class value. It cannot be handled like any other variable. This was demonstrated very clearly with proposal for try. try would have automatically returned with err when err != nil. But what if you wanted to change the error, say create an error message? Then try was completely useless. In Rust, where the result actually is just a regular value, you can transform the error however you like just like any other value and try is just as useful as before.
- marcus_holmes 7y agoSorry, I don't understand what you're saying. Are you saying that because there's a proposal in v2 for error values to not be 1st class values, therefore they're not in v1?
- bambataa 7y agoI think it’s that in Go multiple return values aren’t a first class value. It’s just two separate values. Whereas in Rust or Haskell they’d be a single, first-class Result<a> (or whatever) value.
- kelnos 7y agoThe downside I see with go's error handling is that you can forget to check. With rust, if the function being called returns Result, you have to deal with the error (even if dealing with it just means propagating it out). Missing error handling is such a common source of bugs that go really turns me off here.
- AlexCoventry 7y ago> you can forget to check Linters can help with this.