On Thu, Aug 13, 2026 at 12:00 AM <[email protected]> wrote: > > > 3. Scope: this is a codemaker change, and it cannot be incremental > ------------------------------------------------------------------------ > The specifications are generated. > InterfaceType::dumpExceptionSpecification() > in codemaker/source/cppumaker/cpputype.cxx writes " throw (" onto every UNO > interface method, so every generated .hpp carries them. > > That forces the change to be atomic across the generated/hand-written > boundary. > For a non-destructor virtual function, an override with no specification > may > throw anything -- which is LESS restrictive than a base declaring > throw(RuntimeException), and therefore ill-formed. Strip them from > hand-written > overrides while the generated bases still have them and you simply trade > one > set of errors for another. > > So cppumaker and the sources have to move in the same commit. I mention it > because "start removing them a module at a time" is the natural first > instinct > and it does not work. >
Yes, cppumaker is probably where this change should be made, and leave Java alone. Java will still need exception specifications, as will the IDL to cater for languages such as Java. > > 4. The good news on compatibility > ------------------------------------------------------------------------ > Exception specifications do not participate in name mangling, so this is > not > an ABI break. > I don't know if that's completely true on all platforms, see commits 0a9d806e6889118a07d68c9403d7c84bfac0af44 and 64e326c7e8e93e4234452640047d2d55a6d98111 and fc7f71c8064a223e8598f8729834d18b56bb4bf0. We had to provide exception type_infos at runtime, and their names had to be visible and mangled, although the names of the methods throwing them do not list the exceptions thrown, so maybe it is ABI compatible. > > It is also backward compatible for extensions: once the bases lose their > specifications, a third-party component that still declares > throw(RuntimeException) on its overrides is merely more restrictive, > which is > legal. External UNO components keep compiling unchanged. > > The benefit I see, is that many exceptions are thrown in contradiction of exception specifications (https://bz.apache.org/ooo/show_bug.cgi?id=127252), which is why we use "-fno-enforce-eh-specs" with GCC, and why OpenOffice crashes more often when built with Clang which doesn't have that flag (as throwing an exception that wasn't declared is a serious error, ending in unexpected() -> abort()). So we would have a more stable OpenOffice on FreeBSD (and Mac?), without needing to build with GCC. There would also be better interoperability between languages, as Java throwing to C++ often crashes with Clang for the same reason.
