| The lack of exceptions forces far too many lines of "if err != nil { return err}", (or worse, a goto) which takes 3 lines of text every time. If I could go back in time, and discuss one thing with the designers, it would be to fix this. I'd rather see some kind of Option type (like in Rust) baked deep into the language. Maybe there would be a scheme where you could use these Option types as regular values. The moment you try to use one of them that is actually an error (trying to pass it as an argument to another function without inspecting it first for example), it causes your current function to return an error. Or something like that. Maybe that's a language design change that isn't going to be worked out in a social media post. The "defer" mechanism is clunky. I like defer. Open a file? Defer close it right afterwards in the code. Bam, done! That's nice, and works even if there was a panic deeper in the call stack somewhere. The idiomatic way to do that in Go, however, can mask errors, like say if Close() returned an error, you might not see it if you just did a 'defer foobar.Close()' Those errors should go somewhere... somehow. |
I've seen another way to do it, that works with current Go, in a redis client [1]:
- Function 1 returns rawarg, error where rawarg can be anything
- You want to transform arg into some type, so you create a function that takes a rawarg and an error and returns your type and an error
- In the implementation of your 2nd function, if err != nil, return it directly
This way, as a library user you can just chain your calls without the tedious if err != nil (it will be taken care of in the library).
This might not scale to huge programs, but there certainly is a way to reuse this idea.
[1] https://github.com/garyburd/redigo/blob/master/redis/reply.g...