4 ms·

Wow, I didn’t know Google banned exceptions in their C++ code, but the style guide that is linked indicates that they are indeed banned: https://google.github.

Wow, I didn’t know Google banned exceptions in their C++ code, but the style guide that is linked indicates that they are indeed banned: https://google.github.io/styleguide/cppguide.html#Exceptions https://google.github.io/styleguide/cppguide.html#Exceptions

NBJack 4y ago
Why does this sound familiar? https://go.dev/doc/faq#exceptions https://go.dev/doc/faq#exceptions
- camdenlock 4y ago
  Go = GOAT
DannyBee 4y ago
Yes, they have been banned forever, and not just for size reasons. In the end, it makes code very difficult to reason about. It was a deliberate design goal of C++ exceptions that intermediate libraries/callers/etc do not have to be aware of, or handle, exceptions. There is no way to verify or check that all exceptions are caught by someone, etc. This is, as i said, deliberate. This is quite nice in smaller systems, where you pretty much know every dependency and what calls will do. But in larger, complex systems, where it is very hard to know or control every level of dependency, it is quite painful and fragile, because something 37 levels deep might suddenly throw new exceptions (or exceptions at all), violate 0 of the API guarantees that are being made[1], and start crashing your program in edge cases. Among other things [1] It's very easy for one library to say "we throw exceptions, something must catch them", and the dependent to say "we propagate all exceptions, we don't catch them". Even if something promises to catch them in the middle, it will very quickly get lost as it gets further away from the library actually throwing the exceptions. The fact that you may be able to successfully assign blame or root cause to the problem doesn't help - being able to say something like "this library 36 levels deep in my dependency tree is not following best practices" is not a particularly helpful thing for development.
- ncmncm 4y ago
  This sounds nice but is not true. The bigger the system is, the more value you get from exceptions. The cost is that cleanup operations have to be in destructors. Do that, and exceptions demand almost no attention. Problems show up only when some prima donna declares throwing exceptions from what they call isn't allowed.
  - 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 ago
      1. 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.
  - DannyBee 4y ago
    You literally provide no evidence of your view, just assertions. Not even reasoned argument or examples. Just assertions. Assertions that lots of people who are serious experts in c++, library design, etc, are prima donnas. You see how that isn't particularly helpful or constructive to discussion, right? Maybe you'd like to at least point out the very large scale systems that are using and getting benefits from exceptions, as you claim exists? I can't personally name a single one.

NBJack 4y ago

Why does this sound familiar? https://go.dev/doc/faq#exceptions https://go.dev/doc/faq#exceptions

camdenlock 4y ago
Go = GOAT

DannyBee 4y ago

Yes, they have been banned forever, and not just for size reasons. In the end, it makes code very difficult to reason about. It was a deliberate design goal of C++ exceptions that intermediate libraries/callers/etc do not have to be aware of, or handle, exceptions. There is no way to verify or check that all exceptions are caught by someone, etc. This is, as i said, deliberate. This is quite nice in smaller systems, where you pretty much know every dependency and what calls will do. But in larger, complex systems, where it is very hard to know or control every level of dependency, it is quite painful and fragile, because something 37 levels deep might suddenly throw new exceptions (or exceptions at all), violate 0 of the API guarantees that are being made[1], and start crashing your program in edge cases. Among other things [1] It's very easy for one library to say "we throw exceptions, something must catch them", and the dependent to say "we propagate all exceptions, we don't catch them". Even if something promises to catch them in the middle, it will very quickly get lost as it gets further away from the library actually throwing the exceptions. The fact that you may be able to successfully assign blame or root cause to the problem doesn't help - being able to say something like "this library 36 levels deep in my dependency tree is not following best practices" is not a particularly helpful thing for development.

ncmncm 4y ago
This sounds nice but is not true. The bigger the system is, the more value you get from exceptions. The cost is that cleanup operations have to be in destructors. Do that, and exceptions demand almost no attention. Problems show up only when some prima donna declares throwing exceptions from what they call isn't allowed.
- 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 ago
    1. 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.
- DannyBee 4y ago
  You literally provide no evidence of your view, just assertions. Not even reasoned argument or examples. Just assertions. Assertions that lots of people who are serious experts in c++, library design, etc, are prima donnas. You see how that isn't particularly helpful or constructive to discussion, right? Maybe you'd like to at least point out the very large scale systems that are using and getting benefits from exceptions, as you claim exists? I can't personally name a single one.