I mean, yeah, if your language does not support error values, do not use them.
Nonsense. If adopting info of the many libraries already available is not for you, it’s trivial to roll your own result type.
Even if that was somehow unexplainably not an option, even the laziest of developers can write a function to return a std::tuple or a std::pair and use structured binding.
The problem is not encoding the result.
The problem is that you need some support from the language to make it easy to deal with. Otherwise you’ll get into go-style infinite if (err != null) handlers that will make your code unreadable.
The problem is that you need some support from the language to make it easy to deal with.
Nonsense.
if (result.isSuccess()) {
do_something(result.value);
}
else {
handle_error(result error);
}
I feel like this will have zero protection against
if (result.isSuccess()) {
handle_error(result.error);
} else {
do_something(result.value);
}
Besides, this is exactly what the comment said about having to constantly check for return values at call site. I think this may be mitigated by some clever macro-magic, but that will become a mess fast.
