People that keep bringing this up always miss the rationable that Google code was written initially in a C style that isn't exception safe.
Key takeaway => "Things would probably be different if we had to do it all over again from scratch."
"On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.
Given that Google's existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in a new project. The conversion process would be slow and error-prone. We don't believe that the available alternatives to exceptions, such as error codes and assertions, introduce a significant burden.
Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. Because we'd like to use our open-source projects at Google and it's difficult to do so if those projects use exceptions, we need to advise against exceptions in Google open-source projects as well. Things would probably be different if we had to do it all over again from scratch."
I'm quite happy to NOT have exceptions. I think they're a mistake as a language feature. What we need is first -class support for returning errors and propagating them, like what zig does. The next best thing are those RETURN macros that Google uses.
"first-class support for returning errors and propagating them" certainly sounds like exceptions! In fact, the compiler can even emit special tables that let the runtime completely skip over stack frames that don't need to do any cleanup during that propagation step!
Some languages have even innovated new kinds of exceptions that you can throw but that you are admonished should almost certainly never be caught.
Unfortunately even this is also better for tool support, a problem that using a bunch of macros solves. It's cool and good when a variable gets declared inside the guts of some macro expansion (and--critically--escapes those guts).
Its not the same. You have to explicitly declare the errors and if you want to ignore/propagate them, you have to do so explicitly as well.
You cant invoke a function and pretend it'll never fail.
Also, try/catch with long try blocks and a the error handling at the very end is just bad. Which of the statements in the try is throwing? Even multiple perhaps? Each should be handled individually and immediately
Deliberately more verbose. Not sure how it'd be slower. And only a tiny bit more verbose if the language has nice keywords/syntax for you to use. The point is you want to be explicit when you're choosing to ignore an error.
Both parts of your sentence refer to the Google style guide. This doc isn't the Google style guide. It's the Chromium modern c++ features doc. We don't talk about exceptions or platform-specific stuff (save a note on [[no_unique_address]]) in this doc.
