4 ms·
oddly, the feature that is suggested as being awesome is in fact go's _worst_ feature, which is: value tuples are not error handling. it is not sufficient to
by foxhill 6y ago
oddly, the feature that is suggested as being awesome is in fact go's _worst_ feature, which is:
value tuples are not error handling.
it is not sufficient to rely on an IDE or linter to catch lack of error-case handling. they are semantically identical, and in practise worse, to exceptions: at least exceptions will bubble up, and be caught.. somewhere.
and i'm not saying exceptions are the solution. they really are awful. in my opinion, 'either'/'oneof' types are the best solution here: if something returns either a failure of a success value, then you as a developer are forced to handle the failure condition:
// pseudo c#
either<error, int> result = get_string_length(str);
return reslut.match(left: _ => 0, right: x => x);
you may choose to throw an exception, you may choose to return a default. but you absolutely cannnot _not_ handle this function's failure condition (sorry, double negative..).
- arp242 6y agoGo communicates errors, and you can do something those errors (i.e. handle them). Ergo, it has error handling. It may not be the kind of error handling you like – which is perfectly reasonable – but that's not the same as Go not having error handling.
- cycomanic 6y agoI was about to write the same thing. If your argument about how something is an awesome feature relies on "and most linters or IDEs will likely catch when you missed something or did it wrong" you might not have such a great feature.