# warning: dynamic exception specifications are deprecated in C++11

**URL:** <https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470>\
**Category:** Engineering\
**Created:** [November 30, 2017, 11:03am UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470 "2017-11-30T11:03:40Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![dzenanz](https://discourse.itk.org/user_avatar/discourse.itk.org/dzenanz/32/1093_2.png) [@dzenanz](https://discourse.itk.org/u/dzenanz)\
**Post date:** [December 4, 2017, 6:13pm UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470/21 "2017-12-04T18:13:43Z")

</div>

Time to switch to python3 😄  
What are the current users of ITK+python2? Maybe we should have a discussion about dropping C++03 in a new thread?

---

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [December 4, 2017, 6:16pm UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470/22 "2017-12-04T18:16:47Z")

</div>

I fully support dropping the old compilers and C++03 with a change of the major release number.

---

<div class="post-metadata">

**Author:** ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)\
**Post date:** [December 4, 2017, 6:24pm UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470/23 "2017-12-04T18:24:27Z")

</div>

> [@dzenanz](#):
>
> What are the current users of ITK+python2?

🖐 Mostly because Python 2 is still the default on current stable Linux distributions.

The scientific Python community has made some noise about timelines for dropping support for Python 2 recently, and we may want to keep [NumPy’s timeline](https://github.com/numpy/numpy/blob/master/doc/neps/dropping-python2.7-proposal.rst), in mind, for instance.

---

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [December 4, 2017, 7:57pm UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470/24 "2017-12-04T19:57:12Z")

</div>

Back to noexcept and nothrow, @Matt thank you for sharing that informative link! I didn’t know that `noexcept` was a function specifier AND also an [operator](http://en.cppreference.com/w/cpp/language/noexcept). The may be a defining difference between the two macros.

There may be places where this exception specification could be remove because it is not beneficial. Here is a patch I contributed related to the ( Looks like I introduced ITK\_NOEXCEPT, as for c++03/C++11, then it changed):  
[https://github.com/InsightSoftwareConsortium/ITK/commit/06f8ef0175d901ec5d23197efb4f9044c1b62ab3](https://github.com/InsightSoftwareConsortium/ITK/commit/06f8ef0175d901ec5d23197efb4f9044c1b62ab3)  
[https://github.com/InsightSoftwareConsortium/ITK/commit/cf589ecb34f9dde6bbd5e5779f8ef12516f5d344](https://github.com/InsightSoftwareConsortium/ITK/commit/cf589ecb34f9dde6bbd5e5779f8ef12516f5d344)

From the second patch, it is shown that I was working on ensuring that the execution of the delete event was exception safe. A tricky situation to track down, and ensure defined behavior during deconstruction!

---

<div class="post-metadata">

**Author:** ![phcerdan](https://discourse.itk.org/user_avatar/discourse.itk.org/phcerdan/32/286_2.png) [@phcerdan](https://discourse.itk.org/u/phcerdan)\
**Post date:** [December 5, 2017, 3:45am UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470/25 "2017-12-05T03:45:14Z")

</div>

Good stuff, the standard is confusing indeed, but that link is gold @matt.mccormick.

So, sharing a wrapping up from the [link](https://akrzemi1.wordpress.com/2011/06/10/using-noexcept/) and cppreference.

- Since c++17: `throw()` and `noexcept`, (i.e, the [specifier](http://en.cppreference.com/w/cpp/language/noexcept_spec): `noexcept(true)` ) are exactly the same.
- Pre c++17, `throw()` calls `std::unexpected` instead of `std::terminate` if the function generates a exception. `throw` _specifier_ is deprecated since c++11.  
Also `noexcept` tagged functions can be checked at compile time with the `noexcept` [operator](http://en.cppreference.com/w/cpp/language/noexcept): `noexcept(myfunction)`.  
Note the reason of this post: the [dynamic exception specification](http://en.cppreference.com/w/cpp/language/except_spec): throw(type\_id, type\_id,…) is deprecated since c++11 and has no `noexcept` equivalent.

From: [noexcept specifier (since C++11) - cppreference.com](http://en.cppreference.com/w/cpp/language/noexcept_spec)

> noexcept is an improved version of throw(), which is deprecated in C++11. Unlike pre-C++17 throw(), noexcept will not call std::unexpected and may or may not unwind the stack, which potentially allows the compiler to implement noexcept without the runtime overhead of throw().

- c++03: there is no `noexcept` --specifier or operator–, we use the `throw()` specifier.

#### Proposition:

~~Remove~~ deprecate `ITK_NOEXCEPT_OR_THROW` and use a modified `ITK_NOEXCEPT`:

From itk\_compiler\_detection: `ITK_NOEXCEPT_EXPR(X)` is not used anywhere in ITK (after a fast grep), there is no similar functionality to the `noexcept operator` in c++03. And the valid specifier with `X=false`: `noexcept(false)` is already the default for every function.

Also `ITK_NOEXCEPT` does nothing right know in old compilers, when `throw()` could be used instead

```cpp
    # if ITK_COMPILER_CXX_NOEXCEPT
    # define ITK_NOEXCEPT noexcept
    # define ITK_NOEXCEPT_EXPR(X) noexcept(X)
    # else
    # define ITK_NOEXCEPT
    # define ITK_NOEXCEPT_EXPR(X)
    # endif

```

I propose to deprecate ITK\_NOEXCEPT\_EXPR as well, and directly use the operator `noexcept(expr)` when c++11 is allowed. Right now it can generate invalid code for c++03. From:

```cpp
if( ITK_NOEXCEPT_EXPR(no_throw_function()) )
/* valid c++11:
* if( noexcept(no_throw_function()) ) // true
* invalid c++03
* if()
*/

```

So ~~rename~~ duplicate the macro from itkMacro.h, to deal with the `noexcept` specifier.

```
#if ITK_COMPILER_CXX_NOEXCEPT
#define ITK_NOEXCEPT noexcept
#else
#define ITK_NOEXCEPT throw()
#endif

```

**Edited** :  
Change ITK\_NOEXCEPT to have same behavior than ITK\_NOEXCEPT\_OR\_THROW, and deprecate the latter.  
Remove ITK\_NOEXCEPT from almost everywhere (destructors included), except low-level function such as `Swap`, `Unregister` etc.

---

<div class="post-metadata">

**Author:** ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)\
**Post date:** [December 5, 2017, 3:19pm UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470/26 "2017-12-05T15:19:49Z")

</div>

@phcerdan thanks for taking a stab at a patch 👍

However, from a higher level, to summarize:

- Compilers can do static inspection of the code to determine when exceptions will not be thrown, and they will optimize the binary accordingly.
- It is difficult for a programmer to accurately inspect code and determine whether exceptions will be thrown or not.
- Due to compilers needing to handle the above along with legacy compiler implementation details and the details of how `noexcept` has evolved, use of `noexcept` generally can result in a performance hit instead of a performance gain.
- We should just not use `noexcept`.
- Let’s remove application of `ITK_NOEXCEPT` and `ITK_COMPILER_OR_THROW` and make a comment above these macros that they are no longer used.

---

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [December 5, 2017, 3:38pm UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470/27 "2017-12-05T15:38:00Z")

</div>

I believe that some of the uses can be removed.

However, I think `ITK_NOEXPECT_OR_THROW` may have been added to itk exception classes because the C++03, `throw()` specifier was required, or to suppress a warning. So there is likely a reason why they are there. The specifiers for the exception may be able to be remoted when C++03 support is dropped.

I think marking these core itk object related to reference counting, and command call backs as `noexcept` is important to ensure that our destructors do not emit exceptions. It is my understanding that keeping these specifiers will help enable compiler to emit errors or warnings when these fundamental requirement for compliant destructors is violated.

My suggestions:

- When support for C++03 is dropped, remove ITK\_NOEXCEPT\_OR\_THROW from itk exception objects
- Keep exception specification for core itk objects, LightObject, SmartPointer ( could be convinced otherwise if there are conclusive performance differences across compilers )
- I think the specification for the VariableLengthVector, and in itk::mpl could be removed now

---

<div class="post-metadata">

**Author:** ![fbudin](https://discourse.itk.org/user_avatar/discourse.itk.org/fbudin/32/14_2.png) [@fbudin](https://discourse.itk.org/u/fbudin)\
**Post date:** [December 5, 2017, 3:53pm UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470/28 "2017-12-05T15:53:16Z")

</div>

From the link that Matt shared:

> We said there are two situations where functions do not throw exceptions. The second one is when we intend our function to provide a no-fail guarantee or a no-throw guarantee. The difference between the two guarantees is not trivial. A no-fail guarantee indicates that the function will always succeed in doing what it is supposed to. Such functions are needed by other functions to provide a strong (commit-or-rollback) guarantee. A no-throw guarantee is weaker. It indicates that in case the function fails to do its job, it must not throw exceptions: it might use an error code or some other technique for signalling error, or it may just conceal the fact that it failed. This guarantee is required of functions that are called during stack unwinding where some exception is already being handled and throwing a second one makes the unwinding process to fail. These functions include all destructors, constructors of objects representing exceptions, an conversion operators that return exceptions.

It sounds like objects representing exceptions could also benefit of keeping these keywords.

---

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [December 5, 2017, 3:57pm UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470/29 "2017-12-05T15:57:16Z")

</div>

Looking at this link:

> <https://stackoverflow.com/questions/18416780/overrriding-destructor-of-stdexception>

This is confirmations that classes derived from C++03 std::exception require throw() specification.

---

<div class="post-metadata">

**Author:** ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)\
**Post date:** [December 5, 2017, 4:07pm UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470/30 "2017-12-05T16:07:45Z")

</div>

> [@blowekamp](#):
>
> This is confirmations that classes derived from C++03 std::exception require throw() specification.

Then let’s keep `throw()` around for C++03.

> [@fbudin](#):
>
> It sounds like objects representing exceptions could also benefit of keeping these keywords.

It is not necessary to keep the keywords. C++11 defaults to `noexcept` [when possible](http://en.cppreference.com/w/cpp/language/noexcept_spec). It is better to follow the recommendation of the article:

> First and most important one, if you are concerned about reduced performance, or about the risk of calling std::terminate, or you are just not sure about the new feature, or if you have doubts whether you should make your function noexcept or not, then just do not annotate your functions with noexcept at all.

---

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [December 5, 2017, 4:53pm UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470/31 "2017-12-05T16:53:06Z")

</div>

I have been burned by lack of exception safety in deconstructs of ITK before. The no exception specifiers are important.

---

<div class="post-metadata">

**Author:** ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)\
**Post date:** [December 5, 2017, 6:06pm UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470/32 "2017-12-05T18:06:52Z")

</div>

> [@blowekamp](#):
>
> I have been burned by lack of exception safety in deconstructs of ITK before. The no exception specifiers are important.

Exception safety for destructors are important. `noexcept` is the default for C++11.

---

<div class="post-metadata">

**Author:** ![phcerdan](https://discourse.itk.org/user_avatar/discourse.itk.org/phcerdan/32/286_2.png) [@phcerdan](https://discourse.itk.org/u/phcerdan)\
**Post date:** [December 5, 2017, 11:29pm UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470/33 "2017-12-05T23:29:19Z")

</div>

> [@matt.mccormick](#):
>
> It is not necessary to keep the keywords. C++11 defaults to noexcept when possible. It is better to follow the recommendation of the article:

That makes sense, but quoting the [cpp-coreguidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#f6-if-your-function-may-not-throw-declare-it-noexcept):

> noexcept is most useful (and most clearly correct) for frequently used, low-level functions.  
> Note:  
> Destructors, swap functions, move operations, and default constructors should never throw.

Also check the example in this [issue](https://github.com/isocpp/CppCoreGuidelines/issues/167), relevant if using external libraries with throwing destructors:

> Not all destructors are noexcept by default; one throwing member poisons the whole class hierarchy

I will remove the ITK\_NOEXCEPT\_OR\_THROW from all the destructors and see what happens, but what should we do about the low level functions?  
For example [itkLightObject::Unregister](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkLightObject.h#L108)  
Right now in the codebase, `ITK_NOEXCEPT` expands to `noexpect` (which is a low-level function used frequently) in c++11, and to nothing in c++03!

---

<div class="post-metadata">

**Author:** ![phcerdan](https://discourse.itk.org/user_avatar/discourse.itk.org/phcerdan/32/286_2.png) [@phcerdan](https://discourse.itk.org/u/phcerdan)\
**Post date:** [December 6, 2017, 4:24am UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470/34 "2017-12-06T04:24:29Z")

</div>

> [@phcerdan](#):
>
> I will remove the ITK\_NOEXCEPT\_OR\_THROW from all the destructors and see what happens

Not good, as @blowekamp was saying:  
The `gcc` error about it in c++03:

```cpp
error: looser throw specifier for 'virtual itk::ExceptionObject::~ExceptionObject()'

```

I followerd @blowekamp suggestions:

> [@blowekamp](#):
>
> - When support for C++03 is dropped, remove ITK\_NOEXCEPT\_OR\_THROW from itk exception objects
> - Keep exception specification for core itk objects, LightObject, SmartPointer ( could be convinced otherwise if there are conclusive performance differences across compilers )
> - I think the specification for the VariableLengthVector, and in itk::mpl could be removed now

Keep:

- Child classes of `std::exception` need the destructor specified as `throw()`. In c++11 this is not needed, it is specified by default. This is the most common case in the codebase, and it can be easily removed when c++11 is required.

- Core methods of core objects: itkLightObject::UnRegister, itkSmartPointer, etc. This follows good usage from cpp-coreguidelines as well.

Remove:

- ITK\_NOEXCEPT from regular functions, for example in itkVariableLengthVector and itkBinaryOperationConcept.h. I haven’t found matches in `itk::mpl`

So, basically, I haven’t touch much, beyond the name change. ITK\_NOEXCEPT is already defined outside of itkMacro.h, but it was doing nothing in c++03. I added `throw()` in that case. VNL source code defined the same macro and I opened a PR there: [COMP: Fix VXL\_NOEXCEPT macro. by phcerdan · Pull Request #419 · vxl/vxl · GitHub](https://github.com/vxl/vxl/pull/419).

---

<div class="post-metadata">

**Author:** ![LucH](https://discourse.itk.org/letter_avatar_proxy/v4/letter/l/c5a1d2/32.png) [@LucH](https://discourse.itk.org/u/LucH)\
**Post date:** [December 6, 2017, 1:17pm UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470/35 "2017-12-06T13:17:27Z")

</div>

Hi.

> [@phcerdan](#):
>
> Remove:
> 
> ITK\_NOEXCEPT from regular functions, for example in itkVariableLengthVector and itkBinaryOperationConcept.h. I haven’t found matches in itk::mpl

Why ?  
None of the operations flagged as noexcept in itkVariableLengthVector, or in itkBinaryOperationConcept, throw anything. BTW, it matches std::vector\<\> interface where non-throwing operations are flagged noexcept and CppCoreGuidelines, and many other advices we can found ([vittorio romeo's website](https://vittorioromeo.info/index/blog/compile_time_repeat_noexcept_correctness.html) …)

In all cases if you really want to remove the specifier, it still needs to stay in swap(), and in move operations.

---

<div class="post-metadata">

**Author:** ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)\
**Post date:** [December 6, 2017, 2:44pm UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470/36 "2017-12-06T14:44:45Z")

</div>

> [@LucH](#):
>
> Why ?

[According to a long time developer of the Visual Studio compiler backend](https://github.com/TriangleCppDevelopersGroup/TerryMahaffeyCppTalk), adding `noexcept` can negatively impact performance:

> Current implementation is not as poor, but still unintuitively is a net performance loss – especially on x86

---

<div class="post-metadata">

**Author:** ![LucH](https://discourse.itk.org/letter_avatar_proxy/v4/letter/l/c5a1d2/32.png) [@LucH](https://discourse.itk.org/u/LucH)\
**Post date:** [December 6, 2017, 3:46pm UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470/37 "2017-12-06T15:46:06Z")

</div>

Slide 18, the author recommends to use `/EHsc`, which is equivalent to flag all C functions as `noexcept`. 😕

I understand it could have negative impacts in functions that call other functions that aren’t flagged as noexcept. In VLV case, noexcept is used in leaf functions and other inlined functions that call noexcept functions.

Before removing it, has anyone benchmarked any difference? Or maybe checked the difference on godbolt?

What’s quite sure, if you remove the `noexcept` from move operations, inserting VLV in std::vectors, resizing vectors of VLV, etc. would trigger copies instead of moving the VLV.  
In that case noexcept is required. This will be a net performance loss for sure.

---

<div class="post-metadata">

**Author:** ![phcerdan](https://discourse.itk.org/user_avatar/discourse.itk.org/phcerdan/32/286_2.png) [@phcerdan](https://discourse.itk.org/u/phcerdan)\
**Post date:** [December 6, 2017, 10:12pm UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470/38 "2017-12-06T22:12:31Z")

</div>

> [@LucH](#):
>
> In all cases if you really want to remove the specifier, it still needs to stay in swap(), and in move operations.

Yeah, kept ITK\_NOEXCEPT in VLV in swap functions, move constructor and assignment. It indeed gives the opportunity to big optimizations choosing different algorithms.

In line with the discussion: [c++ - When should I really use noexcept? - Stack Overflow](https://stackoverflow.com/a/12560616/3386303)

---

<div class="post-metadata">

**Author:** ![LucH](https://discourse.itk.org/letter_avatar_proxy/v4/letter/l/c5a1d2/32.png) [@LucH](https://discourse.itk.org/u/LucH)\
**Post date:** [December 7, 2017, 9:51am UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470/39 "2017-12-07T09:51:45Z")

</div>

The second point, and this is only intuition on my side.

`noexcept` is required to call a function if an exception leaks. If the destructor, swap, operator=(&&), and the move-constructor call non-inlined functions that aren’t marked as `noexcept`, I don’t see how the compiler could be able to get rid of the exception-leak check.  
Also, I fail to see why the compiler would introduce a check in `noexcept` functions where it’s clear nothing would throw.

That’s why I did mark all the leaf functions and intermediary functions as `noexcept`, which follows the guideline on C++CoreGuideline & all that recommend to flag `noexcept` functions that’ll never throw. This which is on par with the `/EHsc` option that tell the compiler C functions are `noexcept`.

Before undergoing this cleaning action, it would be interesting to check the difference in the assembly produced by MSVC, GCC, clang, and to measure the processing speed of a resampling of vector image with and without noexcept.

---

<div class="post-metadata">

**Author:** ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)\
**Post date:** [December 7, 2017, 4:14pm UTC](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470/40 "2017-12-07T16:14:51Z")

</div>

Benchmarking to experimentally see what, if any, performance differences occur in practice. I am currently swamped, but I will add vector image resampling test to the [example benchmarks](https://github.com/InsightSoftwareConsortium/ITKPerformanceBenchmarking/tree/master/examples) when I have a chance and see what we get.

[Previous page](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470.md?page=1)

[Next page](https://discourse.itk.org/t/warning-dynamic-exception-specifications-are-deprecated-in-c-11/470.md?page=3)