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 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.
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.