2 ms·
(Opinions are my own) Google uses absl::Status / absl::StatusOr as a replacement for what people would usually use exceptions for. The benefits: 1. As an end
by gravypod 4y ago
(Opinions are my own)
Google uses absl::Status / absl::StatusOr as a replacement for what people would usually use exceptions for.
The benefits:
1. As an end user of a large library I can tell you exactly which calls are "guaranteed" to succeed without learning anything else about the code.
2. It is impossible to ignore a Status/StatusOr which makes it impossible to ignore a failure. You have to explicitly ignore the return value which is easy to spot in code review.
3. You can return your exception across RPC an boundary with added detail so if a caller of your service.
4. You can (very easily) enrich the Status with metadata at every single point. So much so that it is very common.
5. You can enrich the way "exceptions" works in a way that makes sense for your company by changing the structure of Status.
Cons:
1. It is more unnatural than dedicated syntax like try/catch.
2. You can't bubble exceptions up the stack automatically so there are macros that do this for you (https://cs.opensource.google/search?q=ASSIGN_OR_RETURN&sq= https://cs.opensource.google/search?q=ASSIGN_OR_RETURN&sq=)
- germandiago 4y ago1. you usually capture the most general exception in a lib and avoid all refactorings derived of can/cannot fail deep in a stack of calls that needs to be propagated all the way up. With status it happens the same as with stackless coro. Once something is like that, you need to propagate it all the way up. 2. an exception cannot be ignored either. 3. you can transform an exception into a value or even code them as values. 4. See nested_exception.