如何处理错误情况下的对象销毁与非错误情况

How to handle object destruction in error case vs. non-error case

本文关键字：错误 对象 情况 情况下 何处理 处理      更新时间：2023-10-16

我有一个程序，负责读取数据，格式化和创建记录，并将记录输出到文件。此讨论的重要类是：

  • 记录生成器 - 包含控制主流的线程(获取数据、格式、输出(
  • 文件管理器 - 管理输出文件。记录被发送到此类，然后将其放入充电文件中。
  • 输出文件 - 包含记录的文件的抽象，具有打印((，关闭((，等等。这些对象归FileManager所有

在正常进程关闭期间，这些类的析构函数都会被调用，这会导致所有剩余的记录被刷新到当前输出文件，然后关闭。这可确保我们不会丢失任何数据。但是，在错误情况下，我们需要关闭，但我们不想刷新和关闭文件，因为数据可能已损坏。通常，会发生什么是会抛出异常，该异常会被捕获在RecordGenerator然后决定这是否是致命错误。如果是，它将启动应用程序关闭。此时，FileManager被破坏，但需要知道是否存在错误。同样，当FileManager被破坏时，这会导致OutputFile被破坏，这也需要知道是否存在错误。

我的第一反应是添加一些为这些类设置错误标志的公共函数，这样RecordGenerator就可以调用FileManager::setErrorFlag()然后可以调用OutputFile::setErrorFlag()。添加这些链对我来说似乎是一种非常难闻的气味，特别是如果您认为对象链可能比这长得多。

有没有更好的方法来处理这种情况？

当人们开始使用RAII时，这是一个典型的问题。析构函数应清理资源并还原他们负责的任何内容。他们不应提交更改。典型的异常安全C++代码如下所示：

  • 分配资源
  • 做点什么
  • 提交更改

例如：

X& X::operator = (const X& x)
{
    X y(x); // allocate
    this->swap(y); // commit
    return *this;
}
void f()
{
    Transaction t(...); // begin transaction
    // operate
    t.commit(); // commit transaction
}
void g()
{
    File f(...); // open file
    // write to file
    f.flush(); // flush the buffers, this may throw but not f.~File()
}
相关文章：