C++ 是否支持“ finally ”块?
什么是RAII 成语?
C++ 的 RAII 习语和C# 的“使用”语句有什么区别?
在 C++ 中,由于 RAII ,finally不是必需的。
RAII 将异常安全的责任从对象的用户转移到对象的设计者(和实现者)。我认为这是正确的地方,因为您只需要正确地获得一次异常安全(在设计/实现中)。通过使用 finally,您需要在每次使用对象时正确地获得异常安全。
此外,IMO 代码看起来更整洁(见下文)。
例子:
一个数据库对象。为确保使用数据库连接,必须打开和关闭它。通过使用 RAII,这可以在构造函数/析构函数中完成。
void someFunc()
{
DB db("DBDesciptionString");
// Use the db object.
} // db goes out of scope and destructor closes the connection.
// This happens even in the presence of exceptions.
RAII 的使用使得正确使用数据库对象变得非常容易。无论我们如何尝试和滥用它,DB 对象都会通过使用析构函数正确地关闭它自己。
void someFunc()
{
DB db = new DB("DBDesciptionString");
try
{
// Use the db object.
}
finally
{
// Can not rely on finaliser.
// So we must explicitly close the connection.
try
{
db.close();
}
catch(Throwable e)
{
/* Ignore */
// Make sure not to throw exception if one is already propagating.
}
}
}
当最终使用对象时,对象的正确使用被委托给对象的用户。即正确地明确关闭数据库连接是对象用户的责任。现在您可以争辩说这可以在终结器中完成,但是资源可能具有有限的可用性或其他约束,因此您通常确实希望控制对象的释放而不依赖于垃圾收集器的非确定性行为。
这也是一个简单的例子。
当您有多个需要释放的资源时,代码可能会变得复杂。
更详细的分析可以在这里找到:http: //accu.org/index.php/journals/236
RAII 通常更好,但您可以轻松地在 C++ 中使用finally语义。使用少量代码。
此外,C++ Core Guidelines 最后给出。
这是GSL Microsoft 实现的链接和Martin Moene 实现的链接
Bjarne Stroustrup 多次表示,GSL 中的所有内容最终都将纳入标准。所以它应该是一种面向未来的使用finally的方式。
如果您愿意,您可以轻松实现自己,请继续阅读。
在 C++11 RAII 和 lambdas 中,最终允许通用:
namespace detail { //adapt to your "private" namespace
template <typename F>
struct FinalAction {
FinalAction(F f) : clean_{f} {}
~FinalAction() { if(enabled_) clean_(); }
void disable() { enabled_ = false; };
private:
F clean_;
bool enabled_{true}; }; }
template <typename F>
detail::FinalAction<F> finally(F f) {
return detail::FinalAction<F>(f); }
使用示例:
#include <iostream>
int main() {
int* a = new int;
auto delete_a = finally([a] { delete a; std::cout << "leaving the block, deleting a!\n"; });
std::cout << "doing something ...\n"; }
输出将是:
doing something...
leaving the block, deleting a!
我个人使用这几次来确保在 C++ 程序中关闭 POSIX 文件描述符。
拥有一个真正的类来管理资源,从而避免任何类型的泄漏通常会更好,但这最终在创建一个类听起来像是矫枉过正的情况下很有用。
此外,我最终比其他语言更喜欢它,因为如果自然使用,您可以在开始代码附近编写结束代码(在我的示例中为new和delete),并且破坏遵循 C++ 中的 LIFO 顺序构造。唯一的缺点是你得到了一个你并没有真正使用的自动变量,并且 lambda 语法使它有点嘈杂(在我的第四行的例子中,只有finally这个词和右边的 {} 块是有意义的,休息本质上是噪音)。
另一个例子:
[...]
auto precision = std::cout.precision();
auto set_precision_back = finally( [precision, &std::cout]() { std::cout << std::setprecision(precision); } );
std::cout << std::setprecision(3);
如果finally必须在失败的情况下才被调用,则disable成员很有用。例如,您必须在三个不同的容器中复制一个对象,您可以设置finally撤消每个复制并在所有复制成功后禁用。这样做,如果破坏不能扔,你保证了强有力的保证。
禁用示例:
//strong guarantee
void copy_to_all(BIGobj const& a) {
first_.push_back(a);
auto undo_first_push = finally([first_&] { first_.pop_back(); });
second_.push_back(a);
auto undo_second_push = finally([second_&] { second_.pop_back(); });
third_.push_back(a);
//no necessary, put just to make easier to add containers in the future
auto undo_third_push = finally([third_&] { third_.pop_back(); });
undo_first_push.disable();
undo_second_push.disable();
undo_third_push.disable(); }
如果你不能使用 C++11,你仍然可以使用finally,但是代码会变得有点冗长。只需定义一个只有构造函数和析构函数的结构,构造函数引用所需的任何内容,析构函数执行您需要的操作。这基本上是 lambda 所做的,手动完成。
#include <iostream>
int main() {
int* a = new int;
struct Delete_a_t {
Delete_a_t(int* p) : p_(p) {}
~Delete_a_t() { delete p_; std::cout << "leaving the block, deleting a!\n"; }
int* p_;
} delete_a(a);
std::cout << "doing something ...\n"; }
希望你可以使用 C++11,这段代码更多是为了说明“C++ 最终不支持”自 C++ 的最初几周以来一直是无稽之谈,甚至在 C++ 得名之前就可以编写这种代码.
除了使用基于堆栈的对象使清理变得容易之外,RAII 也很有用,因为当对象是另一个类的成员时会发生相同的“自动”清理。当拥有的类被破坏时,由 RAII 类管理的资源被清理,因为该类的 dtor 被调用。
这意味着当您达到 RAII 必杀技并且类中的所有成员都使用 RAII(如智能指针)时,您可以为所有者类使用一个非常简单(甚至可能是默认)的 dtor,因为它不需要手动管理它成员资源生命周期。
为什么即使是托管语言也提供了一个finally块,尽管垃圾收集器会自动释放资源?
实际上,基于垃圾收集器的语言需要“终于”更多。垃圾收集器不会及时销毁您的对象,因此不能依靠它来正确清理与内存无关的问题。
就动态分配的数据而言,许多人认为您应该使用智能指针。
然而...
RAII 将异常安全的责任从对象的用户转移到设计者
可悲的是,这是它自己的垮台。旧的 C 编程习惯很难改掉。当您使用以 C 或非常 C 风格编写的库时,将不会使用 RAII。无需重新编写整个 API 前端,这正是您必须使用的。 然后缺乏“终于”真的很痛苦。
另一个使用 C++11 lambda 函数的“finally”块模拟
template <typename TCode, typename TFinallyCode>
inline void with_finally(const TCode &code, const TFinallyCode &finally_code)
{
try
{
code();
}
catch (...)
{
try
{
finally_code();
}
catch (...) // Maybe stupid check that finally_code mustn't throw.
{
std::terminate();
}
throw;
}
finally_code();
}
希望编译器能优化上面的代码。
现在我们可以编写如下代码:
with_finally(
[&]()
{
try
{
// Doing some stuff that may throw an exception
}
catch (const exception1 &)
{
// Handling first class of exceptions
}
catch (const exception2 &)
{
// Handling another class of exceptions
}
// Some classes of exceptions can be still unhandled
},
[&]() // finally
{
// This code will be executed in all three cases:
// 1) exception was not thrown at all
// 2) exception was handled by one of the "catch" blocks above
// 3) exception was not handled by any of the "catch" block above
}
);
如果你希望你可以把这个成语包装成“try - finally”宏:
// Please never throw exception below. It is needed to avoid a compilation error
// in the case when we use "begin_try ... finally" without any "catch" block.
class never_thrown_exception {};
#define begin_try with_finally([&](){ try
#define finally catch(never_thrown_exception){throw;} },[&]()
#define end_try ) // sorry for "pascalish" style :(
现在“finally”块在 C++11 中可用:
begin_try
{
// A code that may throw
}
catch (const some_exception &)
{
// Handling some exceptions
}
finally
{
// A code that is always executed
}
end_try; // Sorry again for this ugly thing
就我个人而言,我不喜欢“finally”习语的“宏”版本,并且更喜欢使用纯“with_finally”函数,即使在这种情况下语法更庞大。
你可以在这里测试上面的代码:http: //coliru.stacked-crooked.com/a/1d88f64cb27b3813
附言
如果您的代码中需要finally块,那么作用域守卫或ON_FINALLY/ON_EXCEPTION宏可能会更好地满足您的需求。
这是使用 ON_FINALLY/ON_EXCEPTION 的简短示例:
void function(std::vector<const char*> &vector)
{
int *arr1 = (int*)malloc(800*sizeof(int));
if (!arr1) { throw "cannot malloc arr1"; }
ON_FINALLY({ free(arr1); });
int *arr2 = (int*)malloc(900*sizeof(int));
if (!arr2) { throw "cannot malloc arr2"; }
ON_FINALLY({ free(arr2); });
vector.push_back("good");
ON_EXCEPTION({ vector.pop_back(); });
...
很抱歉挖了这么老的帖子,但是下面的推理有一个重大错误:
RAII 将异常安全的责任从对象的用户转移到对象的设计者(和实现者)。我认为这是正确的地方,因为您只需要正确地获得一次异常安全(在设计/实现中)。通过使用 finally,您需要在每次使用对象时正确地获得异常安全。
通常情况下,您必须处理动态分配的对象、对象的动态数量等。在 try 块中,一些代码可能会创建许多对象(有多少是在运行时确定的)并将指向它们的指针存储在列表中。现在,这不是一个奇特的场景,而是非常常见的。在这种情况下,你会想写类似的东西
void DoStuff(vector<string> input)
{
list<Foo*> myList;
try
{
for (int i = 0; i < input.size(); ++i)
{
Foo* tmp = new Foo(input[i]);
if (!tmp)
throw;
myList.push_back(tmp);
}
DoSomeStuff(myList);
}
finally
{
while (!myList.empty())
{
delete myList.back();
myList.pop_back();
}
}
}
当然,列表本身会在超出范围时被销毁,但这不会清理您创建的临时对象。
相反,你必须走丑陋的路线:
void DoStuff(vector<string> input)
{
list<Foo*> myList;
try
{
for (int i = 0; i < input.size(); ++i)
{
Foo* tmp = new Foo(input[i]);
if (!tmp)
throw;
myList.push_back(tmp);
}
DoSomeStuff(myList);
}
catch(...)
{
}
while (!myList.empty())
{
delete myList.back();
myList.pop_back();
}
}
另外:为什么即使是托管语言也提供了一个finally块,尽管垃圾收集器会自动释放资源?
提示:你可以用“finally”做更多的事情,而不仅仅是内存释放。
FWIW,Microsoft Visual C++ 确实支持 try,finally,并且它在历史上一直在 MFC 应用程序中用作捕获严重异常的方法,否则会导致崩溃。例如;
int CMyApp::Run()
{
__try
{
int i = CWinApp::Run();
m_Exitok = MAGIC_EXIT_NO;
return i;
}
__finally
{
if (m_Exitok != MAGIC_EXIT_NO)
FaultHandler();
}
}
我过去用它来做一些事情,比如在退出之前保存打开文件的备份。不过,某些 JIT 调试设置会破坏这种机制。
正如其他答案中所指出的,C++ 可以支持finally
类似的功能。这个功能的实现可能最接近标准语言的一部分,它是伴随着C++ 核心指南的实现,这是一组由 Bjarne Stoustrup 和 Herb Sutter 编辑的使用 C++ 的最佳实践。的实现finally
是指南支持库(GSL) 的一部分。在整个指南中,finally
建议在处理旧式接口时使用 ,并且它也有自己的指南,标题为Use a final_action object to express cleanup if no appropriate resource handle is available。
因此,不仅 C++ 支持finally
,实际上还建议在许多常见用例中使用它。
GSL 实现的示例使用如下所示:
#include <gsl/gsl_util.h>
void example()
{
int handle = get_some_resource();
auto handle_clean = gsl::finally([&handle] { clean_that_resource(handle); });
// Do a lot of stuff, return early and throw exceptions.
// clean_that_resource will always get called.
}
GSL 的实现和使用与Paolo.Bolzoni 的答案中的非常相似。一个区别是由创建的对象gsl::finally()
缺少disable()
调用。如果您需要该功能(例如,在组装后返回资源并且不会发生异常),您可能更喜欢 Paolo 的实现。否则,使用 GSL 与使用标准化功能一样接近。
我有一个用例,我认为它finally
应该是 C++11 语言的一个完全可以接受的部分,因为我认为从流程的角度来看它更容易阅读。我的用例是线程的消费者/生产者链,其中nullptr
在运行结束时发送哨兵以关闭所有线程。
如果 C++ 支持它,你会希望你的代码看起来像这样:
extern Queue downstream, upstream;
int Example()
{
try
{
while(!ExitRequested())
{
X* x = upstream.pop();
if (!x) break;
x->doSomething();
downstream.push(x);
}
}
finally {
downstream.push(nullptr);
}
}
我认为将 finally 声明放在循环的开头更合乎逻辑,因为它发生在循环退出之后......但这是一厢情愿的想法,因为我们不能在 C++ 中做到这一点。请注意,队列downstream
连接到另一个线程,因此您不能将哨兵push(nullptr)
放入析构函数中,downstream
因为此时无法销毁它......它需要保持活动状态,直到另一个线程接收到nullptr
.
所以这里是如何使用带有 lambda 的 RAII 类来做同样的事情:
class Finally
{
public:
Finally(std::function<void(void)> callback) : callback_(callback)
{
}
~Finally()
{
callback_();
}
std::function<void(void)> callback_;
};
下面是你如何使用它:
extern Queue downstream, upstream;
int Example()
{
Finally atEnd([](){
downstream.push(nullptr);
});
while(!ExitRequested())
{
X* x = upstream.pop();
if (!x) break;
x->doSomething();
downstream.push(x);
}
}
不是真的,但你可以在某种程度上模仿它们,例如:
int * array = new int[10000000];
try {
// Some code that can throw exceptions
// ...
throw std::exception();
// ...
} catch (...) {
// The finally-block (if an exception is thrown)
delete[] array;
// re-throw the exception.
throw;
}
// The finally-block (if no exception was thrown)
delete[] array;
请注意,finally 块本身可能会在重新抛出原始异常之前抛出异常,从而丢弃原始异常。这与 Java finally 块中的行为完全相同。此外,您不能return
在 try&catch 块内使用。
我想出了一个finally
可以像¹ finally
Java 中的关键字一样使用的宏;它利用了std::exception_ptr
and Friends、lambda 函数和std::promise
,所以它需要C++11
或以上;它还利用了复合语句表达式GCC 扩展,clang 也支持。
警告:此答案的早期版本使用了该概念的不同实现,但有更多限制。
首先,让我们定义一个辅助类。
#include <future>
template <typename Fun>
class FinallyHelper {
template <typename T> struct TypeWrapper {};
using Return = typename std::result_of<Fun()>::type;
public:
FinallyHelper(Fun body) {
try {
execute(TypeWrapper<Return>(), body);
}
catch(...) {
m_promise.set_exception(std::current_exception());
}
}
Return get() {
return m_promise.get_future().get();
}
private:
template <typename T>
void execute(T, Fun body) {
m_promise.set_value(body());
}
void execute(TypeWrapper<void>, Fun body) {
body();
}
std::promise<Return> m_promise;
};
template <typename Fun>
FinallyHelper<Fun> make_finally_helper(Fun body) {
return FinallyHelper<Fun>(body);
}
然后是实际的宏。
#define try_with_finally for(auto __finally_helper = make_finally_helper([&] { try
#define finally }); \
true; \
({return __finally_helper.get();})) \
/***/
它可以这样使用:
void test() {
try_with_finally {
raise_exception();
}
catch(const my_exception1&) {
/*...*/
}
catch(const my_exception2&) {
/*...*/
}
finally {
clean_it_all_up();
}
}
的使用std::promise
使得它很容易实现,但它也可能引入了相当多的不必要的开销,这可以通过仅从std::promise
.
¹ CAVEAT:有一些东西不像 java 版本的finally
. 在我的头顶上:
break
语句从外部循环中断,因为它们存在于 lambda 函数中;try
catch()
catch()
块try
:这是 C++ 要求;try
如果函数具有除 void 以外的返回值,但在and块中没有返回catch()'s
,则编译将失败,因为finally
宏将扩展为要返回 a 的代码void
。错误地,这可能是一个void ed,因为它有一个finally_noreturn
宏。总而言之,我不知道我自己是否会使用这些东西,但玩它很有趣。:)
正如许多人所说,解决方案是使用 C++11 特性来避免 finally 块。特点之一是unique_ptr
。
这是 Mephane 使用 RAII 模式编写的答案。
#include <vector>
#include <memory>
#include <list>
using namespace std;
class Foo
{
...
};
void DoStuff(vector<string> input)
{
list<unique_ptr<Foo> > myList;
for (int i = 0; i < input.size(); ++i)
{
myList.push_back(unique_ptr<Foo>(new Foo(input[i])));
}
DoSomeStuff(myList);
}
更多关于在 C++ 标准库容器中使用 unique_ptr 的介绍在这里
我还认为 RIIA 并不是异常处理和 finally 的完全有用的替代品。顺便说一句,我也认为 RIIA 是个坏名声。我称这些类型的类为“看门人”并经常使用它们。95% 的时间他们既没有初始化也没有获取资源,他们在范围内应用了一些更改,或者采用已经设置的东西并确保它被销毁。这是官方模式名称痴迷的互联网我被滥用,甚至暗示我的名字可能更好。
我只是认为要求某些特定事物列表的每个复杂设置都必须编写一个包含它的类以避免在面对需要捕获多个事物时清理所有备份时出现并发症是不合理的如果过程中出现问题,则异常类型。这将导致大量的临时课程,否则就没有必要了。
是的,对于旨在管理特定资源的类或旨在处理一组类似资源的通用类来说,这很好。但是,即使涉及的所有事物都有这样的包装器,清理的协调也可能不仅仅是简单的逆序调用析构函数。
我认为 C++ 有一个 finally 是非常有意义的。我的意思是,天哪,在过去的几十年里,有很多零碎的东西粘在它上面,以至于奇怪的人们会突然对像 finally 这样的东西变得保守,这可能非常有用,而且可能没有其他一些东西那么复杂添加(尽管这只是我的猜测。)
已编辑
如果您没有中断/继续/返回等,您可以将捕获添加到任何未知异常并将始终代码放在它后面。这也是您不需要重新抛出异常的时候。
try{
// something that might throw exception
} catch( ... ){
// what to do with uknown exception
}
//final code to be called always,
//don't forget that it might throw some exception too
doSomeCleanUp();
通常,finally 在其他编程语言中通常无论如何都会运行(通常意味着不管任何返回、中断、继续......)除了某种系统exit()
- 每个编程语言有很大不同 - 例如 PHP 和 Java 只是退出时刻,但 Python 最终还是执行然后退出。
但是我上面描述的代码不能那样工作
=>仅 something wrong!
输出以下代码:
#include <stdio.h>
#include <iostream>
#include <string>
std::string test() {
try{
// something that might throw exception
throw "exceptiooon!";
return "fine";
} catch( ... ){
return "something wrong!";
}
return "finally";
}
int main(void) {
std::cout << test();
return 0;
}
try
{
...
goto finally;
}
catch(...)
{
...
goto finally;
}
finally:
{
...
}