warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]

[1209292]

I'm trying to use the library, but the library would not even compile

When I try to compile, I get a long list of warnings. I will paste only one because they are all the same.

`In file included from D:\Program Files\Arduino\libraries\ArduinoSTL\src/memory:20:0,

             from D:\Program Files\Arduino\libraries\ArduinoSTL\src/char_traits:22,

             from D:\Program Files\Arduino\libraries\ArduinoSTL\src/iosfwd:21,

             from D:\Program Files\Arduino\libraries\ArduinoSTL\src/serstream:48,

             from D:\Program Files\Arduino\libraries\ArduinoSTL\src/ArduinoSTL.h:12,

             from C:\Users\jehad\Desktop\TestCppOnArduino\sketch_nov27a\sketch_nov27a.ino:1:

             D:\Program Files\Arduino\libraries\ArduinoSTL\src/new:40:54: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]

              _UCXXEXPORT void* operator new(std::size_t numBytes) throw(std::bad_alloc);

                                                                   ^~~~~`

What am I doing wrong?

[gvansickle]

I'm hitting the same thing, only it's an error in C++17. It's nothing you're doing wrong; "throw()" was deprecated in C++11(or 14? I lose track) and has been removed from C++17 entirely. The library needs to have these removed/replaced. See https://stackoverflow.com/questions/47284705/c1z-dynamic-exception-specification-error If I get enough round tuits I may send in a PR.

[Domigome]

Same issue,

What is the recommended way to go? I don't think I can remove C++17 from my system.

[Zeeshan-2k1]

Reason Exception specifications make error handling brittle, impose a run-time cost, and have been removed from the C++ standard.

Example

int use(int arg)
    throw(X, Y)
{
    // ...
    auto x = f(arg);
    // ...
}

If f() throws an exception different from X and Y the unexpected handler is invoked, which by default terminates. That's OK, but say that we have checked that this cannot happen and f is changed to throw a new exception Z, we now have a crash on our hands unless we change use() (and re-test everything). The snag is that f() might be in a library we do not control and the new exception is not anything that use() can do anything about or is in any way interested in. We can change use() to pass Z through, but now use()'s callers probably need to be modified. This quickly becomes unmanageable. Alternatively, we can add a try-catch to use() to map Z into an acceptable exception. This too quickly becomes unmanageable. Note that changes to the set of exceptions often happen at the lowest level of a system (e.g., because of changes to a network library or some middleware), so changes "bubble up" through long call chains. In a large codebase, this could mean that nobody could update to a new version of a library until the last user was modified. If use() is part of a library, it might not be possible to update it because a change could affect unknown clients.

The policy of letting exceptions propagate until they reach a function that potentially can handle it has proven itself over the years.

Note No. This would not be any better had exception specifications been statically enforced. For example, see Stroustrup94.

Note If no exception can be thrown, use noexcept.

Enforcement Flag every exception specification. Link to know more

[mike-matera]

Hi. I've fixed this in the latest release.