And Google merrily uses C++ with exceptions disabled. That doesn't make it right when the shit hits the fan. "Works most of the time" is not acceptable in an OS.
Would you seriously argue that "works most of the time" does not describe C? Or are you just saying that accepting it for another language is not okay, and anything new allowed into the kernel needs to be perfect instead of just better than C?
Your statement equates not using exceptions with no error handling at all. Are exceptions the only way C++ can handle errors? Or can it do things like return codes used in C or advanced constructs via its metaprogramming?
You can use error codes or, better, a Result<T, E> template in C++, but throwing an exception is the only sane way to signal an error from a C++ constructor that I know of. The alternatives are awkward: you either stick an error code on the struct, which the caller can check after construction, or write an error code to the caller through an out parameter. In either case, the class implementation now must be concerned with handling objects in some partly-initialized, "error" state.
Error handling without exceptions tends to 3x to 5x as much raw code, with corresponding numbers of errors and poorly-exercised paths. Exception paths rely mostly on destructors which are otherwise well-tested in normal operation.
