在 C 语言中是否有一种流行的模仿 Java 的 try/finally 的习惯用法？

Question

从事 Java 工作很多年了，所以一直没有关注 C++。 语言定义中的 C++ 异常处理是否已添加 finally 子句？

有没有一种流行的模仿 Java 的 try/finally 的习惯用法？

我还担心 C++ 没有针对所有可能抛出的异常的最终超类型 - 就像 Java 的 Throwable 类。

我可以写：

try {
  // do something
} catch(...) {
  // alas, can't examine the exception
  // can only do cleanup code and perhaps rethrow, ala:
  throw;
}

附录编辑：

我最终接受了这个答案 得票最多，即使用 析构函数进行清理。 当然， 从我自己的评论来看，很明显我 不完全同意这一点。 然而，C++ 就是这样，所以在 我的申请努力 介意，我或多或少会努力 坚持共同社区 实践。 我将使用模板类 包装尚未拥有的资源 类析构函数（即 C 库 资源），从而赋予他们 析构函数语义。

新附录编辑：

嗯，而不是最后然后是一个闭包 也许有特色？ 闭包结合 ScopeGuard 方法（请参阅其中之一 下面的答案）将是一种方法 任意完成清理 操作和清理权限 代码的外部范围上下文。 清理可以按照 Ruby 编程中常见的惯用方式来完成，其中它们在打开资源时提供清理块。 不是一个 正在考虑的闭合功能 C++？

Answer 1

通过有效地使用析构函数。 当在 try 块中引发异常时，在其中创建的任何对象都将立即被销毁（并因此调用其析构函数）。

这与 Java 不同，在 Java 中，您不知道何时调用对象的终结器。

更新：直接来自马口：为什么不' C++ 提供“finally”结构吗？

Answer 2

我的 0.02 美元。 我多年来一直使用 C# 和 Java 等托管语言进行编程，但为了提高速度，我被迫切换到 C++。 起初我无法相信我如何必须在头文件中写出两次方法签名，然后在 cpp 文件中写出两次，而且我不喜欢没有finally块，并且没有垃圾收集意味着跟踪到处的内存泄漏 -天哪，我一点也不喜欢它！

然而，正如我所说，我被迫使用 C++。 所以我被迫认真学习它，现在我终于理解了像 RAII 这样的所有编程习惯，并且我了解了该语言的所有微妙之处等等。 我花了一段时间，但现在我发现它与 C# 或 Java 相比有多么不同。

如今我认为 C++ 是最好的语言！ 是的，我可以理解有时会多一些我所说的“干扰”（看似不必要的东西来写），但在实际认真使用该语言之后，我完全改变了我的想法。

我以前一直有内存泄漏的情况。 我曾经将所有代码写入 .h 文件，因为我讨厌代码分离，我无法理解他们为什么要这样做！ 我过去总是以愚蠢的循环包含依赖关系而告终，而且还有更多。 我真的很迷恋 C# 或 Java，对我来说 C++ 是一个巨大的退步。 这些天我明白了。 我几乎从来没有内存泄漏，我喜欢接口和实现的分离，并且我不再有循环依赖的问题。

我也不会错过finally 块。 老实说，我的观点是，您所说的在 catch 块中编写重复的清理操作的这些 C++ 程序员对我来说听起来就像他们只是糟糕的 C++ 程序员。 我的意思是，看起来该线程中的任何其他 C++ 程序员都没有遇到您提到的任何问题。 RAII 确实让最终变得多余，而且如果有的话，那就是工作量减少了。 您编写了一个析构函数，然后您最终就不必再编写另一个析构函数了！ 至少对于那种类型来说是这样。

恕我直言，我认为现在的情况是您现在已经习惯了 Java，就像我以前一样。

Answer 3

C++ 的答案是 RAII：对象的析构函数将在超出范围时执行。 无论是通过返回、异常还是其他方式。 如果您在其他地方处理异常，则可以确保从被调用函数到处理程序的所有对象都将通过调用其析构函数来正确销毁。 他们会为你打扫卫生。

阅读http://en.wikipedia.org/wiki/Resource_acquisition_is_initialization

Answer 4

Nofinally 还没有被添加到 C++ 中，也不可能被添加。

C++ 使用构造函数/析构函数的方式使得不需要finally。
如果您使用 catch(...) 进行清理，那么您没有正确使用 C++。 清理代码应该全部位于析构函数中。

尽管不要求使用它，但 C++ 确实有 std::exception。
强制开发人员从特定类派生以使用异常违背了 C++ 的“保持简单”理念。 这也是为什么我们不要求所有类都从 Object 派生的原因。

阅读： C++ 支持“finally”块吗？ （我一直听说的“RAII”是什么？）

使用finally 进行清理比使用析构函数更容易出错。
这是因为您强制对象的用户而不是类的设计者/实现者进行清理。

Answer 5

好的，我必须添加对您在单独的答案帖子中提出的观点的答案：
（如果您将其编辑到原始问题中，会方便得多，这样它就不会出现在答案下方的底部。

如果所有清理工作总是在
那么就不需要析构函数
是 catch 中的任何清理代码
块 - 但 C++ 有 catch 块，其中
清理行动完成。 确实如此
有一个 catch(...) 块，它在哪里
只能执行清理操作
（好吧，当然不能得到任何
执行任何操作的异常信息
记录）。

catch 有一个完全独立的目的，作为 Java 程序员，您应该意识到这一点。 finally 子句用于“无条件”清理操作。 无论如何退出区块，都必须这样做。 Catch 用于有条件的清理。 如果抛出此类异常，我们需要执行一些额外的操作。

finally 块中的清理将
完成是否有
是否抛出异常 - 这是
当一个人总是希望发生什么时
清理代码确实存在。

真的吗？ 如果我们希望这种类型总是发生（例如，我们总是希望在完成数据库连接后关闭它），那么为什么我们不定义它一次< /em>? 在类型本身？ 让数据库连接自行关闭，而不是在每次使用它时都进行尝试/最终操作？

这就是析构函数的要点。 它们保证每种类型在每次使用时都能够处理自己的清理工作，而调用者不必考虑它。

C++ 开发人员从第一天起就一直
饱受必须重复清理的困扰
出现在 catch 块中的操作
发生的代码流
成功退出 try 块。
Java 和 C# 程序员就这么做
一旦进入finally块。

不会。C++ 程序员从来没有受过这个困扰。 C 程序员有。 C 程序员意识到 C++ 有类，然后称自己为 C++ 程序员。

我每天都用 C++ 和 C# 编程，我觉得我被 C# 可笑的坚持所困扰，即我每次使用数据库连接或其他东西时都必须提供一个 finally 子句（或 using 块）必须清理掉。

C++ 让我可以一劳永逸地指定“每当我们完成此类型时，它都应该执行这些操作”。 我不会冒忘记释放内存的风险。 我不会冒忘记关闭文件句柄、套接字或数据库连接的风险。 因为我的内存、句柄、套接字和数据库连接都是自行完成的。

每次使用类型时都必须编写重复的清理代码，这怎么可能更好呢？ 如果您需要包装类型，因为它本身没有析构函数，您有两个简单的选择：

• 寻找提供此析构函数的适当 C++ 库（提示：Boost）
• 使用 boost::shared_ptr 包装它，并提供它在运行时使用自定义函子，指定要完成的清理。

当你编写应用服务器时
Java EE 应用程序服务器等软件
Glassfish、JBoss 等等，你想成为
能够捕获并记录异常
信息——而不是让它
落在地板上。 或者更糟糕的是陷入
运行时并导致不优雅
应用程序服务器突然退出。
这就是为什么非常希望拥有
任何的总体基类
可能的例外。
而C++就有这样一个类。 std::异常。

从 CFront 时代起就开始使用 C++
这十年的大部分时间都是 Java/C#。 是
清楚地看到有一个巨大的
文化差距从根本上如何
类似的事情正在接近。

不，你从来没有学过 C++。 您已经完成了 CFront，或者带有类的 C。 不是C++。 有很大的不同。 别再说这些答案蹩脚了，你可能会学到一些你认为你懂的语言的知识。 ;)

Answer 6

清理功能本身就非常蹩脚。 他们的凝聚力较低，因为他们期望执行一系列仅与活动发生时间相关的活动。 它们具有高耦合性，因为当实际执行某些操作的函数发生更改时，它们需要修改其内部结构。 因此，它们很容易出错。

try...finally 构造是清理函数的框架。 这是一种语言鼓励的编写糟糕代码的方式。 此外，由于它鼓励一遍又一遍地编写相同的清理代码，因此破坏了 DRY 原则。

对于这些目的，C++ 方式要好得多。 资源的清理代码在析构函数中只编写一次。 它与该资源的其余代码位于同一位置，因此具有良好的内聚性。 清理代码不必放入不相关的模块中，因此这减少了耦合。 如果设计得当，它只需一次编写。

而且，C++的方式更加统一。 C++ 添加了智能指针，以相同的方式处理各种资源，而 Java 可以很好地处理内存，但提供的结构不足以释放其他资源。

C++ 有很多问题，但这不是其中之一。 Java 在某些方面比 C++ 更好，但这不是其中之一。

Java 如果有一种实现 RAII 的方法而不是 try...finally 会更好。

Answer 7

为了避免必须为每个可释放资源定义包装类，您可能对 ScopeGuard (http:// www.ddj.com/cpp/184403758），它允许人们即时创建“清洁器”。

例如：

FILE* fp = SomeExternalFunction();
// Will automatically call fclose(fp) when going out of scope
ScopeGuard file_guard = MakeGuard(fclose, fp);

Answer 8

一个例子说明正确使用finally是多么困难。

打开和关闭两个文件。
您想要保证文件正确关闭的地方。
等待 GC 不是一个选择，因为文件可能会被重复使用。

在 C++ 中

void foo()
{
    std::ifstream    data("plop");
    std::ofstream    output("plep");

    // DO STUFF
    // Files closed auto-magically
}

，在没有析构函数但有finally 子句的语言中。

void foo()
{
    File            data("plop");
    File            output("plep");

    try
    {
        // DO STUFF
    }
    finally
    {
        // Must guarantee that both files are closed.
        try {data.close();}  catch(Throwable e){/*Ignore*/}
        try {output.close();}catch(Throwable e){/*Ignore*/}
    }
}

这是一个简单的示例，代码已经变得很复杂。 这里我们只尝试整理 2 个简单的资源。 但随着需要管理的资源数量的增加和/或其复杂性的增加，在存在异常的情况下正确使用finally块变得越来越困难。

最后的使用将正确使用的责任转移到对象的用户身上。 通过使用 C++ 提供的构造函数/析构函数机制，您可以将正确使用的责任转移给类的设计者/实现者。 这本质上是更安全的，因为设计者只需要在类级别正确地执行一次（而不是让不同的用户尝试以不同的方式正确地执行它）。

Answer 9

使用 C++11 及其 lambda 表达式，我最近开始使用下面的代码来模仿finally：

class FinallyGuard {
private:
  std::function<void()> f_;
public:
  FinallyGuard(std::function<void()> f) : f_(f) { }
  ~FinallyGuard() { f_(); }
};

void foo() {
  // Code before the try/finally goes here
  { // Open a new scope for the try/finally
    FinallyGuard signalEndGuard([&]{
      // Code for the finally block goes here
    });
    // Code for the try block goes here
  } // End scope, will call destructor of FinallyGuard
  // Code after the try/finally goes here
}

FinallyGuard是一个用可调用的类似函数的参数（最好是lambda表达式）构造的对象。 它只会记住该函数，直到调用其析构函数为止，这是当对象超出范围时的情况，无论是由于正常的控制流还是由于异常处理期间的堆栈展开。 在这两种情况下，析构函数都会调用该函数，从而执行相关代码。

有点奇怪的是，您必须在 try 块的代码之前编写 finally 的代码，但除此之外，它实际上感觉很像 Java 中的真正的 try/finally。 我想人们不应该在具有自己适当的析构函数的对象更合适的情况下滥用这种方法，但在某些情况下我认为上述方法更合适。 我在这个问题中讨论了一个这样的场景。

据我了解， std::function 将使用一些指针间接寻址和至少一个虚拟函数调用来执行其 类型擦除，因此会有性能开销。 不要在性能至关重要的紧密循环中使用此技术。 在这些情况下，其析构函数只做一件事的专用对象会更合适。

Answer 10

C++ 析构函数使 finally 变得多余。 通过将清理代码从finally移至相应的析构函数，可以获得相同的效果。

Answer 11

我认为您没有抓住 catch (...) 的作用。

您在示例中说“唉，无法检查异常”。 好吧，您没有有关异常类型的信息。 您甚至不知道它是否是多态类型，因此即使您有某种对它的无类型引用，您甚至无法安全地尝试dynamic_cast。

如果您了解可以使用的某些异常或异常层次结构，那么这就是具有显式命名类型的 catch 块的位置。

catch (...) 在 C++ 中并不常用。 它可以用在必须保证不抛出或仅抛出某些约定异常的地方。 如果您使用 catch (...) 进行清理，那么您的代码在任何情况下都很可能不是稳健的异常安全的。

正如其他答案中提到的，如果您使用本地对象来管理资源（RAII），那么您经常需要很少的 catch 块，这可能会令人惊讶和启发 - 如果您不需要在本地执行任何异常操作 - 即使是try 块可能是多余的，因为您让异常流出到可以响应它们的客户端代码，同时仍然保证没有资源问题。

为了回答您最初的问题，如果您需要在块末尾运行一些代码，无论是否有异常，那么配方就是。

class LocalFinallyReplacement {
    ~LocalFinallyReplacement() { /* Finally code goes here */ }
};
// ...
{ // some function...
    LocalFinallyReplacement lfr; // must be a named object

    // do something
}

请注意我们如何完全取消 try、catch 和 throw。

如果函数中的数据最初是在 try 块之外声明的，并且需要在“finally”块中访问，那么您可能需要将其添加到辅助类的构造函数中，并将其存储到析构函数中。 然而，此时我会认真重新考虑是否可以通过更改本地资源处理对象的设计来解决问题，因为这意味着设计中存在问题。

Answer 12

并非完全偏离主题。

Java 中的 Boiler Plate DB 资源清理

讽刺模式：不是吗Java 习语精彩吗？

Answer 13

在这 15 年里，我用 C++ 进行了大量的类设计和模板包装设计，并且在析构函数清理方面全部采用 C++ 方式完成。 然而，每个项目也总是涉及 C 库的使用，这些库提供了打开它、使用它、关闭它的使用模型的资源。 try/finally 意味着这样的资源可以在需要的地方被消耗——以一种完全健壮的方式——并完成它。 对这种情况进行编程的最简单的方法。 可以处理清理逻辑期间发生的所有其他状态，而不必在某些包装器析构函数中进行限制。

我的大部分 C++ 编码都是在 Windows 上完成的，因此在这种情况下总是可以使用 Microsoft 的 __try/__finally 。 （它们的结构化异常处理具有一些与异常交互的强大能力。）唉，看起来 C 语言从未批准过任何可移植的异常处理结构。

但这并不是理想的解决方案，因为在 try 块中混合 C 和 C++ 代码并不简单，因为在 try 块中可能会抛出任何一种类型的异常。 添加到 C++ 中的finally 块对于这些情况会有帮助，并且可以实现可移植性。

Answer 14

关于您的附录编辑，是的，C++0x 正在考虑闭包。 它们可以与 RAII 作用域防护一起使用，以提供易于使用的解决方案，请检查 Pizer 的博客。 它们还可以用于模仿 try-finally，请参阅 这个答案； 但是这真的是吗好主意吗？。

Answer 15

我想我应该添加我自己的解决方案 - 一种智能指针包装器，用于当您必须处理非 RAII 类型时。

像这样使用：

Finaliser< IMAPITable, Releaser > contentsTable;
// now contentsTable can be used as if it were of type IMAPITable*,
// but will be automatically released when it goes out of scope.

这里是 Finaliser 的实现：

/*  Finaliser
    Wrap an object and run some action on it when it runs out of scope.
    (A kind of 'finally.')
    * T: type of wrapped object.
    * R: type of a 'releaser' (class providing static void release( T* object )). */
template< class T, class R >
class Finaliser
{
private:
    T* object_;

public:
    explicit Finaliser( T* object = NULL )
    {
        object_ = object;
    }

    ~Finaliser() throw()
    {
        release();
    }

    Finaliser< T, R >& operator=( T* object )
    {
        if (object_ != object && object_ != NULL)
        {
            release();
        }
        object_ = object;

        return *this;
    }

    T* operator->() const
    {
        return object_;
    }

    T** operator&()
    {
        return &object_;
    }

    operator T*()
    {
        return object_;
    }

private:
    void release() throw()
    {
        R::release< T >( object_ );
    }
};

... 这里是 Releaser：

/*  Releaser
    Calls Release() on the object (for use with Finaliser). */
class Releaser
{
public:
    template< class T > static void release( T* object )
    {
        if (object != NULL)
        {
            object->Release();
        }
    }
};

我有几种不同类型的释放器，包括一种用于 free() 和一种用于 CloseHandle()。