【C++ 异常 】深入了解C++ 异常机制中的 terminate（）处理 避免不必要的错误（二）

【C++ 异常 】深入了解C++ 异常机制中的 terminate（）处理 避免不必要的错误（一）https://developer.aliyun.com/article/1467409

6.1.2 自定义终止处理程序

尽管std::terminate()的默认行为是终止程序，但C++标准库允许我们设置一个自定义的终止处理程序来替换默认的处理程序。这可以通过std::set_terminate()函数来实现。

#include <iostream>
#include <stdexcept>
void customTerminate() {
    std::cerr << "Custom terminate handler called" << std::endl;
    exit(1);  // 退出程序
}
int main() {
    std::set_terminate(customTerminate);  // 设置自定义的终止处理程序
    throw std::runtime_error("An error occurred!");
}

在上面的示例中，我们设置了一个自定义的终止处理程序customTerminate()。当程序中抛出一个未捕获的异常时，这个处理程序会被调用。

从心理学的角度看，提供这种自定义能力是非常有意义的。它允许开发者在面对未知的、不可预测的错误时，有机会在最后的时刻进行一些清理工作，或者给用户提供一些有用的反馈。这种能力满足了人们对控制的基本需求，即使在面对不确定性时也能保持一定的控制感。

6.2 调用栈的解开与资源泄漏

当异常被抛出但没有被捕获时，与异常相关的调用栈不会自动解开。这意味着任何在抛出异常的路径上的局部对象都不会被正确地销毁。

6.2.1 局部对象的生命周期

在C++中，局部对象的生命周期是由它们的作用域决定的。当控制流离开一个对象的作用域时，该对象的析构函数会被自动调用。但是，如果在对象的作用域内抛出了一个异常，并且这个异常没有在该作用域内被捕获，那么该对象的析构函数不会被调用。

这可能会导致资源泄漏或其他未定义的行为。例如，如果一个对象持有一个文件句柄或网络连接，并依赖于其析构函数来关闭这些资源，那么未捕获的异常可能会导致这些资源不被正确地释放。

#include <iostream>
#include <stdexcept>
class ResourceHolder {
public:
    ResourceHolder() {
        std::cout << "Resource acquired" << std::endl;
    }
    ~ResourceHolder() {
        std::cout << "Resource released" << std::endl;
    }
};
int main() {
    try {
        ResourceHolder rh;
        throw std::runtime_error("An error occurred!");
    } catch (const std::exception& e) {
        std::cerr << e.what() << std::endl;
    }
}

在上面的示例中，即使在ResourceHolder对象的作用域内抛出了一个异常，由于我们提供了一个catch块来捕获这个异常，ResourceHolder对象的析构函数仍然会被调用，从而释放资源。

6.2.2 资源管理与异常安全

在C++中，资源管理通常是通过RAII（Resource Acquisition Is Initialization，资源获取即初始化）模式来实现的。这是一个非常强大的模式，它确保了资源的正确管理，即使在面对异常时也是如此。

但是，如果我们没有正确地使用RAII，或者在面对异常时没有考虑到所有的情况，那么可能会导致资源泄漏或其他问题。

从心理学的角度看，人们通常倾向于避免考虑负面的情况

，特别是在面对复杂的问题时。这就是为什么在编程中，我们经常会忽略异常情况或错误处理。但是，通过深入了解和学习RAII和异常安全的技术，我们可以更好地应对这些挑战，并编写更加健壮和可靠的代码。

6.3 核心转储与调试

在某些配置下，未捕获的异常可能会导致程序崩溃并生成核心转储文件（core dump）。这个核心转储文件可以用于后续的调试，以确定导致异常的原因。

6.3.1 Linux下的核心转储机制

在Linux系统中，当一个进程由于某种原因（如段错误或未捕获的异常）而异常终止时，操作系统可以生成一个核心转储文件。这个文件包含了进程在崩溃时的内存映像，可以用于后续的调试。

为了生成核心转储文件，我们需要确保系统的配置允许这样做。这可以通过ulimit命令来实现：

ulimit -c unlimited

这个命令将核心转储文件的大小限制设置为无限，从而确保任何大小的核心转储文件都可以被生成。

一旦核心转储文件被生成，我们可以使用gdb（GNU调试器）来分析它：

gdb ./my_program core

在这里，my_program是导致核心转储的程序的可执行文件，core是核心转储文件的名称。

通过使用gdb，我们可以查看崩溃时的调用栈，检查变量的值，甚至执行一些命令来模拟程序的执行。这为我们提供了一个非常强大的工具，可以深入地了解导致崩溃的原因。

7. 异常与多线程

在现代计算中，多线程和并发编程已经成为了一个不可或缺的部分。但是，当我们将异常处理与多线程结合起来时，会出现一些新的挑战和问题。在这一章中，我们将深入探讨这些问题，并提供一些策略和技巧来应对它们。

7.1 线程间的异常传播

在单线程程序中，异常的传播是相对直接的：异常从它被抛出的地方开始，沿着调用栈向上传播，直到它被一个catch块捕获或到达主函数main()的顶部。但在多线程环境中，情况就变得复杂了。

7.1.1 线程局部性与异常

在C++中，每个线程都有自己的调用栈。这意味着，当一个线程抛出一个异常时，这个异常只能在该线程的调用栈中传播。它不能跨线程传播或被其他线程捕获。

这种线程局部性的设计是有意为之的，因为跨线程的异常传播会引入很多复杂性和不确定性。但这也意味着，如果一个线程抛出了一个异常，但没有捕获它，那么只有这个线程会被终止，其他线程会继续执行。

这种行为可以通过以下示例来说明：

#include <iostream>
#include <thread>
#include <stdexcept>
void threadFunction() {
    throw std::runtime_error("Exception from thread");
}
int main() {
    std::thread t(threadFunction);
    t.join();
    std::cout << "Main thread continues..." << std::endl;
}

在上面的示例中，我们在一个新线程中抛出了一个异常。但是，这个异常不会影响主线程的执行，主线程会继续执行并打印出"Main thread continues…"。

从心理学的角度看，这种设计可以看作是一种“隔离”策略。当一个线程遇到问题时，它不会影响其他线程的执行。这种隔离策略可以帮助我们将问题局限在一个小的范围内，而不是让它影响整个程序。

7.1.2 异常与std::future

C++11引入了std::future和std::promise，这两个类提供了一种在多线程中传递数据和异常的机制。

当我们使用std::async或std::promise在一个线程中执行一个任务，并返回一个std::future时，如果这个任务抛出了一个异常，这个异常会被捕获并存储在std::future中。然后，当我们在另一个线程中调用std::future::get()时，这个异常会被重新抛出。

这提供了一种在多线程中传递异常的机制，而不是直接终止线程。

#include <iostream>
#include <future>
#include <stdexcept>
int main() {
    auto future = std::async(std::launch::async, []() {
        throw std::runtime_error("Exception from async task");
        return 42;
    });
    try {
        int result = future.get();
        std::cout << "Result: " << result << std::endl;
    } catch (const std::exception& e) {
        std::cerr << "Caught exception: " << e.what() << std::endl;
    }
}

在上面的示例中，我们在一个异步任务中抛出了一个异常。这个异常被捕获并存储在std::future中。然后，当我们调用future.get()时，这个异常被重新抛出，并被catch块捕获。

这种设计提供了一种灵活的方式，可以在多线程中处理异常，而不是直接终止线程。从心理学的角度看，这为我们提供了一种“缓冲”机制，可以在适当的时间和地点处理异常，而不是立即对其做出反应。

7.2 线程安全与异常处理

在多线程环境中，确保代码的线程安全是非常重要的。但当我们引入异常处理时，这会增加额外的复杂性。

7.2.1 异常安全的锁管理

在多线程编程中，我们经常使用锁（如std::mutex）来确保对共享资源的独占访问。但是，如果在持有锁的代码中抛出了一个异常，并且这个异常没有被捕获，那么锁可能永远不会被释放，导致死锁或其他问题。

为了避免这种情况，我们可以使用RAII原则来管理锁。C++标准库提供了std::lock_guard和std::unique_lock，这两个类都遵循RAII原则，确保锁在任何情况下都会被正确地释放。

#include <iostream>
#include <mutex>
#include <stdexcept>
std::mutex mtx;
void safeFunction() {
    std::lock_guard<std::mutex> lock(mtx);  // 自动获取锁
    // ... 代码 ...
    throw std::runtime_error("Exception with lock held
");
    // 当lock对象被销毁时，锁会自动被释放
}
int main() {
    try {
        safeFunction();
    } catch (const std::exception& e) {
        std::cerr << "Caught exception: " << e.what() << std::endl;
    }
}

在上面的示例中，我们使用std::lock_guard来自动获取和释放锁。即使在持有锁的代码中抛出了一个异常，锁仍然会被正确地释放。

7.2.2 异常与条件变量

在多线程编程中，我们经常使用条件变量（如std::condition_variable）来同步线程的执行。但是，如果在等待条件变量的代码中抛出了一个异常，这可能会导致线程永远不会被唤醒，或者条件变量的状态变得不确定。

为了避免这种情况，我们需要确保在等待条件变量时不会抛出任何异常，或者确保异常被适当地捕获和处理。

#include <iostream>
#include <mutex>
#include <condition_variable>
#include <stdexcept>
std::mutex mtx;
std::condition_variable cv;
bool ready = false;
void waitForCondition() {
    std::unique_lock<std::mutex> lock(mtx);
    while (!ready) {
        cv.wait(lock);  // 在这里等待条件变量
    }
    // ... 代码 ...
    throw std::runtime_error("Exception after waiting");
}
int main() {
    try {
        std::thread t(waitForCondition);
        // ... 代码 ...
        {
            std::lock_guard<std::mutex> lock(mtx);
            ready = true;
            cv.notify_all();  // 唤醒所有等待的线程
        }
        t.join();
    } catch (const std::exception& e) {
        std::cerr << "Caught exception: " << e.what() << std::endl;
    }
}

在上面的示例中，我们在等待条件变量时没有抛出任何异常。但是，在等待之后的代码中抛出了一个异常。这确保了条件变量的状态始终是确定的，而不会被异常中断。

从心理学的角度看，这种方法可以帮助我们减少不确定性和复杂性，从而使我们的代码更加健壮和可靠。

8. 异常信号与系统层面的处理

在C++编程中，异常处理是一个核心的概念，但在系统层面，异常的处理与信号处理有着紧密的联系。本章将深入探讨SIGABRT信号的特性、信号处理与异常机制的交互，以及信号安全与异常处理。在此过程中，我们将结合心理学的知识，深入剖析程序员在面对这些技术挑战时的心理反应和应对策略。

8.1 SIGABRT信号的特性

当我们谈论SIGABRT（中文：中止信号），我们实际上是在描述一个由程序异常行为引发的信号。这通常是由于程序内部的某种严重错误，如断言失败。

8.1.1 信号的来源

在Unix-like系统中，信号是进程间通信的一种机制。SIGABRT是其中之一，通常由程序自身发出，表示程序中存在严重的问题。

例如，当我们使用C++标准库中的assert宏并且断言失败时，就会产生SIGABRT信号。

#include <cassert>
int main() {
    assert(false);  // 这会触发SIGABRT信号
    return 0;
}

8.1.2 信号的处理

默认情况下，SIGABRT会导致程序终止并生成核心转储文件。但是，我们可以使用signal()或sigaction()函数来捕获并处理这个信号。然而，这并不总是一个好主意。正如心理学家弗洛伊德（Sigmund Freud）所说：“人类不应该逃避现实，而应该面对它。” 在编程中，这意味着我们应该避免忽略或误处理这些严重的错误信号。

8.2 信号处理与异常机制的交互

信号处理与C++的异常机制是两个独立的概念，但它们在某些情况下可能会交互。

8.2.1 信号处理函数中抛出异常

在信号处理函数中抛出异常是不安全的。因为信号处理函数是由操作系统异步调用的，它可能在任何时间、任何地点中断程序的正常执行。如果在这样的上下文中抛出异常，可能会导致未定义的行为。

例如，考虑以下代码：

#include <csignal>
#include <iostream>
#include <exception>
void handle_signal(int signal) {
    if (signal == SIGABRT) {
        throw std::runtime_error("Caught SIGABRT");
    }
}
int main() {
    std::signal(SIGABRT, handle_signal);
    std::abort();  // 触发SIGABRT信号
    return 0;
}

在上述代码中，当SIGABRT信号被触发时，handle_signal函数会尝试抛出一个异常。但这是不安全的，因为我们不能保证在信号处理函数中抛出的异常会被正确处理。

【C++ 异常 】深入了解C++ 异常机制中的 terminate（）处理 避免不必要的错误（三）https://developer.aliyun.com/article/1467411