forked from amazingfate/loongoffice
eb0cfb3bf2
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: 0295bd6b3f21dd648af6145ca23d90467f3cec73 155cd09b5eebe0c1eab0610a7f1f04f09de4b217 Change-Id: I9c7664c9f1b238f4f9501aacb065981236949440