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