The thing that kills me about Go's error handling is you return error AND value all the time. It's like an Either that always has Left and Right. I think it's a bummer, especially coming from a group that has developed languages in the past.
The thing that kills me about Go's error handling is you return error AND value all the time. It's like an Either that always has Left and Right. I think it's a bummer, especially coming from a group that has developed languages in the past.
I'm not a Go user, but if I understand correctly ("It's like an Either that always has Left and Right."), functions return a structure with both an error code and a value.
To wrap a C function into a Go function with this signature, you can initialize a structure with { code: success; value:f() }; and then of course error checking has to be done C-style (errno, lib_last_error(), etc).
The problem with tagged unions is that when you access the wrong field (when it's not enforced by the language), everything can happen : you can build ill-formed values, jump to random places, etc. Having an explicit NULL in that cases is better.
In a nutshell, unsafe tagged unions < explicit NULLs < safe tagged unions.
> How is that any worse than the current situation of not checking the error side and reading an undefined (or whatever it is?) value?
You get deterministic failure modes instead of dragons flying out of your nose.
Also assigning error in a variable ignoring it sticks out a lot more. The single-return value C version doesn't tell you if it can return failure or not.
edit: fixed quoting
What Go currently has does not solve this problem, which is what I'm pointing out. Your argument is basically "not handling the error Looks Bad". Mine is "It should be impossible to do wrong". Something like ADT's would have been very welcomed, then we could just have a classy option type or either type.