cppumaker: do write exception specifications on --enable-dbgutil
Exception specifications are useless for production code, but make for useful assertions in dbgutil builds (on platforms where they are enforced at runtime). Because we do not have API tests that exhaustively trigger all documented error conditions, much less the undocumented or wrongly handled error conditions that would cause the implementation to violate its API specification, there is likely some benefit in having these runtime-checked specifications in debug builds, in the hope that our various tests which may incidentally call various API methods, or general soffice usage, uncovers these bugs. Also, there may be some benefit to making API implementers more aware of the exception specifications, to quote Stephan's mail: To be able to programmatically react to an exception raised by a UNO method (which is the raison d'être of non-runtime UNO exceptions), the specification of that method must document the method's behavior with respect to raising that exception, and any implementation of the method must adhere to that specification. However, with that part of a UNO method's interface moved out of sight of a programmer writing a C++ implementation of that method, I fear that adherence to specification will degrade in practice. And that negatively affects an area where we do not shine anyway: reaction to errors. This partially reverts commits: 0295bd6b 155cd09b Change-Id: I9c7664c9f1b238f4f9501aacb065981236949440
Showing
Please
register
or
sign in
to comment