> EDIT (March 1, 2026): I updated the title to to clarify that this observation is specific to my environment. The original title may have implied a universal behavior, which isn’t the case. Thanks for the feedback!
I really hate that, and believe if they would have been there since the beginning, the split would not have happened as the option to disable them would not exist in first place.
It was introduced for historical compatibility reasons, it is not officially supported on the standard, but some folks really keep on using non-standard language, spitting the libraries ecosystem.
Even rust let's you turn panics into asserts. It saves a lot of binary size and arguably is equally debugable. We also see improved performance from being more cache friendly. C++ usage wouldn't be nearly as high if there wasn't such an option. As far as I'm concerned the primary downside is not being able to return errors in constructors and handle allocation failures but both are solve able via some common idioms (static methods and custom placement new)
Constructors and destructors can have function level try-catch blocks.
Yes the syntax could have been much better.
As proven by ongoing work done by Khalil Estell, in some embedded scenarios exceptions aren't that great only due to quality of implementation, someone added the support and call it done, no effort at all to improve it.
Even Ada's Ravenscar profile does allow for exceptions in high integrity computing scenarios, in embedded systems.
Well I for one, if that would mean less "C programming with C++ compiler" that still plagues the security history to this day, great they can keep using C for that.
It's often a requirement for bare metal embedded development (too heavy in terms of memory), so it's basically unavoidable. Non-standard languages are very common for this kind of thing, just look at the linux-flavoured C.