Exceptions are often a better way to handle errors than returning them as values. We argue that traditional exceptions provide better user and developer experience, and show that they even result in faster execution.
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 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.
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.
I feel like this will have zero protection against
Zero protections against what? Against the programmer telling the program to do something it shouldn’t? Not programming language does that. If you resort to this sort of convoluted reasoning, the same hypothetical programmer can also swallow all exceptions.
The main problem you’re creating for yourself is that you’ve been given an open-ended problem but instead prefer to not look for solutions.
I mean, technically there’s nothing preventing that, but in practice it’s a fairly uncommon mistake to make and it’s immediately obvious that there’s an issue the first time that path is taken. If something like that makes it to production, it clearly points to an issue with test coverage rather than code paradigm.
In C++, ignoring anything that any other language provides…
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.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.
Zero protections against what? Against the programmer telling the program to do something it shouldn’t? Not programming language does that. If you resort to this sort of convoluted reasoning, the same hypothetical programmer can also swallow all exceptions.
The main problem you’re creating for yourself is that you’ve been given an open-ended problem but instead prefer to not look for solutions.
I mean, technically there’s nothing preventing that, but in practice it’s a fairly uncommon mistake to make and it’s immediately obvious that there’s an issue the first time that path is taken. If something like that makes it to production, it clearly points to an issue with test coverage rather than code paradigm.