4 ms·
It's my favorite thing about Go.[0] Even in C++ I use error values instead of exceptions, regardless of RAII, so it was a natural transition to Go. Although I'd
by mratzloff 10y ago
It's my favorite thing about Go.[0] Even in C++ I use error values instead of exceptions, regardless of RAII, so it was a natural transition to Go. Although I'd like to see what a C-style language with Common Lisp-style error conditions and restarts would look like. Ruby has a little bit of that functionality with `redo` and `retry`.
[0] Followed by multiple return values, duck-typed interfaces, automatic pointer dereferencing, channels, and a rich standard library. Sorry, this didn't begin as a rah-rah Go post.
- fauigerzigerk 10y agoThe problem I have with Go's error handling is that it makes you choose: Either you write a function that can return errors or you write a function that can be used as part of a larger expression. It can never be both. result := f() * g() becomes x, err := f() if err != nil { //handle f() err } y, err := g() if err != nil { //handle g() err } result := x * y Even without exceptions I can imagine to have something like result, err := f() * g() if err != nil { //handle err } Of course that raises a lot of other questions if functions can have side-effects (but possibly no more so than shortcut logical operators)
- mratzloff 10y agoYou must choose, but there's nothing stopping you from collecting errors in the background and creating a monad. Return a maybe value and expose a way to access the error.
- fauigerzigerk 10y agoWhat's stopping me from doing that more often than I do is that it's too much work. Collecting errors is just part of it. You also have to make sure nothing that has side effects gets called after the first one. Without language support this is tortuous and error prone.