{"id":5483,"date":"2018-08-10T15:56:36","date_gmt":"2018-08-10T15:56:36","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/c-core-guidelines-when-you-can-t-throw-an-exception\/"},"modified":"2024-12-05T11:24:35","modified_gmt":"2024-12-05T11:24:35","slug":"c-core-guidelines-when-you-can-t-throw-an-exception","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/c-core-guidelines-when-you-can-t-throw-an-exception\/","title":{"rendered":"C++ Core Guidelines: finally in C++"},"content":{"rendered":"

To make my point clear, this post is about the exceptional case that you can not throw an exception. If your program runs in a restricted embedded environment or you have to fulfil a hard-real-time requirement, this situation may be not so exceptional to you.<\/p>\n

<\/p>\n

\"accident

Bild von succo<\/a> auf Pixabay<\/a><\/p><\/div>\n

Let’s start with the exceptional environment in which you can’t throw exceptions. My original plan was to write at least about the rules E.19 to E.27. But I get stuck at rule E.19.<\/p>\n

<\/span>E.19: Use a final_action<\/code> object to express cleanup if no suitable resource handle is available<\/a><\/span><\/h2>\n

The first rule may surprise you because you have never heard about final_action<\/span>. Me too. Therefore I researched. During my research, I found an excellent post on this rule by Bart\u0142omiej Filipek<\/strong>.\u00a0Bart\u0142omiej Filipek is the author of the well-known C++-blog: Bartek’s coding blog<\/a>. With his permission, I’m happy to incorporate his post Beautiful code: final_act from GSL<\/a> into my post. Here we are.<\/p>\n

Sometimes there\u2019s a need to invoke a particular action at the end of the scope: it could be a resource releasing code, flag set, code guard, begin\/end function calls, etc. Recently, I\u2019ve found a beautiful utility that helps in that cases.
\nLet\u2019s meet gsl::final_act<\/code>\/finally<\/code>.<\/span><\/p>\n

<\/span>Intro<\/span><\/h3>\n

Follow-up<\/strong> post here: link<\/a>.<\/p>\n

Imagine we have the following code:<\/p>\n

\n
void<\/span> addExtraNodes<\/span>();\nvoid<\/span> removeExtraNodes<\/span>();\n\nbool<\/span> Scanner::<\/span>scanNodes()\n{\n    \/\/ code...<\/span>\n    addExtraNodes();\n\n    \/\/ code...<\/span>\n    removeExtraNodes();\n    return<\/span> true<\/span>;\n}\n<\/pre>\n<\/div>\n
We have a bunch of objects that scanNodes<\/code><\/span><\/strong> scans (global or shared container), but we need to add some extra nodes to check. We want to preserve the initial container state, so in the end, we must remove those additional nodes.<\/p>\n
Of course, the design of the whole scan code could be much better so that we work on a copy of the container, and adding or removing extra stuff would not be a problem. But there are places, especially in legacy code, where you work on some global container, and special care needs to be taken when changing it. Many bugs can happen when you modify a state and someone expects a different state of the shared container.<\/p>\n
My code seems to be working as expected\u2026 right? I call removeExtraNodes<\/code><\/span><\/strong> at the end of the function.<\/p>\n
But what if there are multiple returns from scanNodes<\/code><\/span><\/strong>? It\u2019s simple: we need to add multiple calls to removeExtraNodes<\/code>.<\/span><\/strong> Ok\u2026.<\/p>\n
What if there are some exceptions thrown? Then we also need to call our cleanup function before we throw\u2026<\/p>\n
So it appears we need to call removeExtraNodes<\/code><\/span><\/strong> not only before the last return!<\/p>\n
<\/span>Help needed<\/span><\/h3>\n
Let\u2019s look at the C++ Core Guidelines. They suggest doing the following thing:<\/p>\n
E.19: Use a final_action object to express cleanup if no suitable resource handle is available<\/a><\/p>\n
The guideline says that we should strive for a better design, but still, it\u2019s better than goto; exit approach or doing nothing.<\/p>\n
Ok\u2026 but what\u2019s the solution here:<\/p>\n
\n
bool<\/span> Scanner::<\/span>scanNodes()\n{\n    \/\/ code...<\/span>\n    addExtraNodes();\n    auto<\/span> _ =<\/span> finally([] { removeExtraNodes(); });\n\n    \/\/ code...<\/span>\n\n    return<\/span> true<\/span>;\n}\n<\/pre>\n<\/div>\n
What happened here?<\/p>\n
All I did was wrap the call to removeExtraNodes<\/code><\/strong><\/span>\u00a0a particular object that will call a given callable object in its destructor. This is precisely what we need!<\/p>\n
Where can we find that magical finally()<\/code><\/span> code?<\/p>\n
Just see Guideline Support Library\/gsl_util.h<\/a>.<\/p>\n
<\/span>Under the hood<\/span><\/h3>\n
The code is short, so I can even paste it here:<\/p>\n
\n
template<\/span> <<\/span>class<\/span> F<\/span>><\/span>\nclass<\/span> final_act<\/span>\n{\npublic:<\/span>\n    explicit<\/span> final_act(F f) noexcept \n      :<\/span> f_(std::<\/span>move(f)), invoke_(true<\/span>) {}\n\n    final_act(final_act&&<\/span> other) noexcept \n     :<\/span> f_(std::<\/span>move(other.f_)), \n       invoke_(other.invoke_)\n    {\n        other.invoke_ =<\/span> false<\/span>;\n    }\n\n    final_act(const<\/span> final_act&<\/span>) =<\/span> delete<\/span>;\n    final_act&<\/span> operator<\/span>=<\/span>(const<\/span> final_act&<\/span>) =<\/span> delete<\/span>;\n\n    ~<\/span>final_act() noexcept\n    {\n        if<\/span> (invoke_) f_();\n    }\n\nprivate:<\/span>\n    F f_;\n    bool<\/span> invoke_;\n};\n<\/pre>\n<\/div>\n
Isn\u2019t that beautiful?!<\/p>\n
The above class takes a callable object – f_<\/code><\/span><\/strong> It will call it when it\u2019s about to be destroyed. So even if your code returns early or throws an exception, your cleanup code must be invoked.<\/p>\n
To work nicely with move semantics, there has to be an additional boolean parameter invoke_<\/code><\/span><\/strong>. This will guarantee that we won\u2019t call the code for temporary objects. See this commit for more information if needed: 
\nFinal_act copy\/move semantics is wrong<\/a>.<\/p>\n
In C++17, we have <\/span>Template argument deduction for class templates<\/span><\/a><\/span> \u2013 that\u2019s why you can also declare final_act<\/span> object as: <\/span><\/span><\/p>\n
\n
final_act _f<\/span>([] { removeExtraNodes(); })<\/pre>\n<\/div>\n
Before C++17, we had to use the helper function finally<\/span> to make our life easier:<\/p>\n
\n
template<\/span> <<\/span>class<\/span> F<\/span>><\/span>\ninline<\/span> final_act<<\/span>F><\/span> finally(const<\/span> F&<\/span> f) noexcept\n{\n    return<\/span> final_act<<\/span>F><\/span>(f);\n}\n\ntemplate<\/span> <<\/span>class<\/span> F<\/span>><\/span>\ninline<\/span> final_act<<\/span>F><\/span> finally(F&&<\/span> f) noexcept\n{\n    return<\/span> final_act<<\/span>F><\/span>(std::<\/span>forward<<\/span>F><\/span>(f));\n}\n<\/pre>\n<\/div>\n
So, all in all, we can use finally()<\/code>\u00a0the function in the client code. Maybe that could change in C++17 as we\u2019ll get Template argument deduction for class templates<\/a>.<\/p>\n
What\u2019s nice about this code?<\/p>\n