Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


On 12/02/2012 09:03 PM, Michael Stahl wrote:
so... following the above reasoning i have just re-enabled the exception
specifications with eb0cfb3bf220892e4885945452930790f5e22000; they are
written only in an --enable-dbgutil build.

what is still missing then is a macro for use in the API implementations
that expands to nothing unless --enable-dbgutil is set; presumably a
cleanup to use such a macro everywhere should be done together with
replacing the ::com::sun::star in the exception specs with ::css, which
should make the clutter a bit less annoying.

Sounds like a use-case for a refurbished SAL_WARN, which expands to nothing in exactly those cases where we want to elide runtime checks for unexpected but have no other way to do so (e.g., no -fno-enforce-eh-specs in Clang). And then, it would probably be better to have cppumaker generate SAL_THROW-style exception specifications in all cases, so that e.g. somebody developing C++ code in a GCC --disable-dbgutil scenario would not inadvertently forget those dynamic exception specifications in newly written code.

Stephan

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.