[Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

Charley Bay charleyb123 at gmail.com
Thu Aug 2 15:05:45 CEST 2012


Thiago spaketh:

> I'd like to propose we add Q_DECL_NOEXCEPT to many methods in our API.
>
> We already took the decision to turn exception off in most modules, except
> QtCore and where exceptions were used, like QtXmlPatterns. This is the next
> step.
>
> The Q_DECL_NOEXCEPT macro expands to noexcept, which is a new C++11
> keyword.
> It is equivalent to noexcept(true), also new in C++11, and it means the
> method
> declares that it does not throw any exceptions.
>
> The benefits are:
>  - callers do not need to emit exception handlers around such functions
>  - the compiler may assume that no exception unexpectedly happens inside
> that
> function body, foregoing exception handlers inside it as well.
>
> The first behaviour is present with a C++03's empty exception specification
> (i.e., throw() in the function declaration), but the second behaviour is
> new
> in C++11. In the previous standard, the compiler was forced to emit
> exception
> code for the case when exceptions did happen even when they shouldn't. For
> that reason, the C++03 exception specification is deprecated.
>
> The drawback is that it makes the code ugly.
>
> The macro expands to nothing in C++98 mode. That means code using the API
> so
> marked and compiling in C++98 mode will simply not gain the benefits of the
> keyword, but should see no side effects.
>
> The presence of the keyword does not affect binary compatibility. With the
> Itanium C++ ABI, it's not present in the mangling. MSVC2010 does not
> supoprt
> it yet, so I cannot verify what it does. However, since C++11 support
> cannot
> be turned on or off on it, the keyword will be enabled or it won't
> depending on
> the compiler version, which means that binary compatibility is irrelevant.
> But
> if it does encode it in the mangling, we will not be able to add the
> keyword
> to methods in 5.1 or later.
>

Totally agree, support Q_DECL_NOEXCEPT being added to many methods in the
API.

I've seen many developers confuse "exception-handling" with
normal-error-handling, and think it would be best to establish clarity for
those operations that do not throw (and which logically should never throw).

This is consistent with the C++11 intent of "increased type safety", and we
should use it, IMHO.  The benefits seem compelling:

(a) It better documents the design/implementation details
(b) It may lead to more efficient compiled-binary

I concede Thiago's identified drawback:

(c) It makes the code ugly

...however, it adds-the-caveat that the code "ugliness" is the same as
saying it better documents the design/implementation detail.  Since this is
a cross-platform reusable library and users rely upon the Qt docs anyway, I
don't think that's much of a penalty (if any).


> The question that remains is: what methods shall we add this to? We can
> add it
> to any method for which we can *prove* that it will never throw, which are:
>  - leaf functions
>  - functions calling only C functions or other noexcept functions
>
> Outside of QtCore, I propose we add it only to methods that are called
> often
> and frequently. In QtCore, I propose we add it to most tool methods that
> are
> provably noexcept. For example, the qHash functions, QMutex, our memory
> allocation routines (the throwing is in inline code), etc.
>
> PS: to be clear: new throws.


I'd vote to "add-it-everywhere-possible", starting with those Thiago
identified.  IMHO it should be "good practice" for developers to
add-this-to-their-API-review-checklist to use the "Q_DECL_NOEXCEPT"
everywhere possible as they grow/maintain their APIs.

--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120802/b5e8302f/attachment.html>


More information about the Development mailing list