4

Item 14 of "Effective Modern C++" recommends declaring functions noexcept whenever they don't emit exceptions. I have a class with a number of small member functions that cannot throw for very trivial reasons e.g. they only perform simple mathematical operations on PODs. Should I declare such functions noexcept? It seems like overkill to me when even the compiler can surely detect that there is no possibility of throwing.

EDIT: To clarify my question somewhat, the advice given in this question is to "use it when it's obvious that the function will never throw." But if it's obvious (even to the compiler) that the function will never throw, why use noexcept at all? Note that I would have to mark the overwhelming majority of the functions my program as noexcept, which I will only do if given a compelling reason.

Community
  • 1
  • 1
Alessandro Power
  • 2,395
  • 2
  • 19
  • 39
  • @JesperJuhl I saw that question before but did not find it helpful, as the advice reduced to "use it whenever it's obvious the function will never throw" without providing any rationale. If it's obvious the function won't throw, why bother adding `noexcept`? – Alessandro Power Jan 07 '17 at 15:47
  • because it may not be obvious to the compiler and it also provides extra documentation to users of your API. – Jesper Juhl Jan 07 '17 at 15:49
  • @JesperJuhl I edited my question to make this clearer, but it should be obvious to the compiler that the functions in question cannot throw as they consist merely of branching, simple arithmetic, loops etc. There is no memory allocation or anything that might conceivably throw. – Alessandro Power Jan 07 '17 at 15:55
  • 1
    @AlessandroPower: You've fallen into the trap of interpreting a keyword according to the English words it appears to be made of, rather than its actual definition. `nothrow` does not mean "none of the code in this function can throw", rather it means "no exception will escape from this function". The difference manifests two ways -- it's perfectly allowed to have code that does throw, if the function catches the exception. And exceptions may escape that are not thrown intrinsically (from the function's own code), but from a function called from this function. – Ben Voigt Jan 07 '17 at 19:10
  • 1
    In general, for the compiler to infer whether a function intrinsically leaks exceptions is easy, but extrinsic exceptions, especially in the presence of polymorphism or indirection, require annotations (`nothrow` keyword). – Ben Voigt Jan 07 '17 at 19:11

1 Answers1

2

But if it's obvious (even to the compiler) that the function will never throw, why use noexcept at all?

That knowledge can be only inferred by knowing the definition of the function. The callers will likely include only the header, which contains the declaration. No information there. Your best chance is that the link time optimizer notices the implicit noexcept property and removes the exception handling (talking purely about theoretical considerations, not sure if compilers actually do this...).

This, of course, it's not possible in several circumstances, for example if you use your object polymorphically. Though your implementation is implicity noexcept, the function of the subclass might very well throw.

As a sidenote, life is usually fine and dandy without noexcept, so unless there's a specific reason you want to use it, e.g. a public API, a performance sensitive tight loop, coding standards, etc. you're free to omit it. Do not micro optimize or waste time.

Karoly Horvath
  • 94,607
  • 11
  • 117
  • 176