Overall, I agree. Exceptions are messy and make it difficult to reason about code. That said, I think the macro at the bottom is even worse. I think a better solution to the one posted in the article is to use std::expected instead. This gives you a typed union that allows you to return either a successful result or an error type.
What's nice about it is that you don't need to add endless amounts of if success {...} else {...} blocks. You can use the monadic operations (and_then, transform, etc.) to add your logic as normal while letting the compiler smoothly take care of doing the error checks. (In fact, I really wish golang has something similar to this, it would get rid of the endless error checking you have to write manually.)
I wasn't able to find an example using std::expected, and I tried writing one myself, but my version of g++ doesn't seem to support it yet. But here is a nice std::optional example that should be pretty close to what you would do with std::expected.
The main problem with std:: expected is lack of language support. In theory, it works well as an alternative to exceptions, with nice self contained monadic statements. In practice, it is actually much worse than what the article suggests.
main issues -
as I said, no language level support. You eventually end up with messy code somewhere because the library code can't simplify things enough. You end up with if checks strew about that really oaught to be a language paradigm.
there is not a lot of code making use of it, so at the boundaries of your code you have to make adaptations to and from std:: expected from whatever some library chose to use.
adapting your existing codebase is basically impossible. Perhaps if you are starting a new project you can do it, but it is different enough that all your existing code must be updated to accommodate the new paradigm and it's just an awful experience doing the work and being in a mix of error handling.
Overall, I agree. Exceptions are messy and make it difficult to reason about code. That said, I think the macro at the bottom is even worse. I think a better solution to the one posted in the article is to use
std::expected
instead. This gives you a typed union that allows you to return either a successful result or an error type.What's nice about it is that you don't need to add endless amounts of
if success {...} else {...}
blocks. You can use the monadic operations (and_then
,transform
, etc.) to add your logic as normal while letting the compiler smoothly take care of doing the error checks. (In fact, I really wish golang has something similar to this, it would get rid of the endless error checking you have to write manually.)I wasn't able to find an example using
std::expected
, and I tried writing one myself, but my version of g++ doesn't seem to support it yet. But here is a nicestd::optional
example that should be pretty close to what you would do withstd::expected
.The main problem with
std:: expected
is lack of language support. In theory, it works well as an alternative to exceptions, with nice self contained monadic statements. In practice, it is actually much worse than what the article suggests.main issues -
as I said, no language level support. You eventually end up with messy code somewhere because the library code can't simplify things enough. You end up with if checks strew about that really oaught to be a language paradigm.
there is not a lot of code making use of it, so at the boundaries of your code you have to make adaptations to and from
std:: expected
from whatever some library chose to use.adapting your existing codebase is basically impossible. Perhaps if you are starting a new project you can do it, but it is different enough that all your existing code must be updated to accommodate the new paradigm and it's just an awful experience doing the work and being in a mix of error handling.
I guess you mean
std::expected
, notstd::exception
?