2 ms·
It depends on the problem domain. For automotive embedded software? Definitely not. But Google, for instance, bans them in much of its server code under the pri
by shadowgovt 3y ago
It depends on the problem domain. For automotive embedded software? Definitely not. But Google, for instance, bans them in much of its server code under the principle that exceptions should denote circumstances where the entire program cannot recover and when a server node cannot recover, logging noisily and failing fast so that it can be restarted into a working state is preferable to trying to unwind a bad state.
Given that constraint, they conclude that the overhead of maintaining exception unwinding and the non-local control flow aren't worth it.
- cpgxiii 3y agoThe classic GSG prohibition on exceptions has more to do with a lack of exception safety in their legacy code base than anything else. Promptly-crash-on-failure can be achieved by adopting a "don't catch exceptions" style, with significant advantages of not throwing away much of the strengths of RAII or needing the evil hack that is two-phase initialization.
- shadowgovt 3y agoYou can for all intents and purposes avoid two phase init with factory functions (which is how Go does it) and private constructors. (To my memory though, Google didn't throw away the benefits of RAII without allowing exceptions... They discouraged complicated behavior in constructors and so the only thing a constructor could fail on was OME, which was supposed to crash anyway).
- otabdeveloper4 3y agoAll Google code is a huge antipattern and an example of enterprise coding gone insane.