在上一篇文章中简单介绍了一下 RAII 的原理, 举了个读文件的例子. 这个例子稍微单薄了一些, 它只封装了一个需要 RAII 机制管理的资源 (FILE*). 软件工程中流行的观念是, 不具备扩展性, 经不起追加功能的东西注定会悲剧. 现在假如需要给这货增加个缓冲区, 也许这样是可以的

struct File {
    File(char const* filename, int buffer_size)
        : file(fopen(filename, "r"))
        , buffer(new char[buffer_size])
    {
        if (NULL == file) {
            throw std::runtime_error(std::string("fail to open ") + filename);
        }
    }

    ~File()
    {
        fclose(file);
        delete[] buffer;
    }
private:
    FILE* file;
    char* buffer;

/* other members */
};

    在 buffer 分配失败时, 一般会抛出 std::bad_alloc.
    这个类型的破绽相当多, 稍不注意就有可能漏资源. 首先是刚刚提到的 buffer 分配失败抛异常, 那么假如这个时候 file 已经打开成功了, 它会被关闭么? 其次, 假设 buffer 成功分配, 但这时 file 打开失败, 那么 buffer 是否会被释放呢?
    很不幸的, 两者的答案都是否. 还是那句话, 因为 File 的构造函数没有走完, 这时抛出异常, 那么析构函数不会被执行. 因此, 不要尝试构造控制多于一个资源的类型. 而遇到这种需求, 应该拆分资源, 然后将这些单元类型进行聚合, 如

struct File {
    explicit File(char const* filename)
        : file(fopen(filename, "r"))
    {
        if (NULL == file) {
            throw std::runtime_error(std::string("fail to open ") + filename);
        }
    }

    ~File()
    {
        fclose(file);
    }
private:
    FILE* file;

/* other members */
};

struct Buffer {
    explicit Buffer(int buffer_size)
        : buffer(new char[buffer_size])
    {}

    ~Buffer()
    {
        delete[] buffer;
    }
private:
    char* buffer;

/* other members */
};

struct BufferedFile {
    BufferedFile(char const* filename, int buffer_size)
        : file(filename)
        , buffer(buffer_size)
    {}

    File file;
    Buffer buffer;

/* other members */
};

Posted at Jun 21 2011 - 13:27:55

Permanent Link: /p/363 Load full text

Post tags:

RAII
Exception Handling
C++

从 Python 的 with 到 RAII

在上一篇文章中提到了 Python 的 with 结构, 其背后的思想正是 RAII. 在 C++ 中, RAII 的样子看起来跟 Python 中的会非常不一样, 还是以打开读取文件为例子

#include <cstdio>
#include <stdexcept>
#include <iostream>

struct File {
    explicit File(char const* filename)
        : f(fopen(filename, "r"))
    {
        if (NULL == f) {
            throw std::runtime_error(std::string("fail to open ") + filename);
        }
    }

    std::string readLine()
    {
        char buffer[256] = { 0 }; // just for demo
        if (NULL == fgets(buffer, 256, f)) {
            if (!feof(f)) {
                throw std::runtime_error("error occurs while reading file");
            }
            throw std::out_of_range("end of file")
        }
        return buffer;
    }

    ~File()
    {
        fclose(f);
    }
private:
    FILE* const f;
};

int main()
{
    try {
        File file("litsu");
        while (true) {
            std::cout << file.readLine();
        }
    } catch (std::runtime_error e) {
        std::cerr << e.what() << std::endl;
    } catch (std::out_of_range) {}
    return 0;
}

注意看 try 块中间的语句, 看起来流程很清晰, 完全不像 Python 里面那样, 还要弄个 with 块, 多一级缩进. 都说 C++ 代码没 Python 的精神, 然而在这种小地方 C++ 反而超过了 Python 呢.

其实, Python 的 with 块更像个语法糖, 上篇文章中有提到, 双层 try 在 Python 中能等效地解决这个问题, 只是看起来丑很多. 这个问题的根本在于, Python 这样不具备 RAII 特性的语言没能处理好对象从不可用状态切换到可用状态的状态过渡. 回顾一下双层 try 结构的处理方式

def readFile():
    try:
        f = open('sawako', 'r')
        pass
        try:
            process(f.readlines())
        except:
            print 'error occurs while reading file'
        finally:
            f.close()
    except:
        print 'error occurs while reading file'

Posted at Jun 20 2011 - 08:43:07

Permanent Link: /p/358 Load full text

Post tags:

Exception Handling
C++
RAII
Python

Python: try finally with 简介

用 Python 做一件很平常的事情: 打开文件, 逐行读入, 最后关掉文件; 进一步的需求是, 这也许是程序中一个可选的功能, 如果有任何问题, 比如文件无法打开, 或是读取出错, 那么在函数内需要捕获所有异常, 输出一行警告并退出. 代码可能一开始看起来是这样的

def read_file():
    try:
        f = open('yui', 'r')
        print ''.join(f.readlines())
    except:
        print 'error occurs while reading file'
    finally:
        f.close()

不过这显然无法运作, 因为 f 是在 try 块中定义的, 而在 finally 中无法引用.

如果将 f 提取到 try 块外部, 如

def read_file():
    f = open('azusa', 'r')
    try:
        print ''.join(f.readlines())
    except:
        print 'error occurs while reading file'
    finally:
        f.close()

那么, 问题在于当打开文件失败, 抛出异常将不会被捕获.

挫一点的方法自然是, 再套一层 try 吧

def read_file():
    try:
        f = open('sawako', 'r')
        try:
            print ''.join(f.readlines())
        except:
            print 'error occurs while reading file'
        finally:
            f.close()
    except:
        print 'error occurs while reading file'

当然这不仅仅是多一层缩进挫了, 连警告输出都白白多一次呢.

正规一点的方式是, 使用 Python 引入的 with 结构来解决, 如

def readFile():
    try:
        with open('mio', 'r') as f:
            print ''.join(f.readlines())
    except:
        print 'error occurs while reading file'

    当文件打开失败时, 异常自然会被 except 到; 否则, 在 with 块结束之后, 打开的文件将自动关闭.

    除了打开文件, 还有其它这样可以用于 with 的东西么? 或者说, 怎么自定义一个什么东西, 让它能用于 with 呢?
    直接回答后一个问题吧, 秘密在于 Python 虚拟机在 with 块退出时会去寻找对象的 __exit__ 方法并调用它, 把释放资源的动作放在这个 __exit__ 函数中就可以了; 另外, 对象还需要一个 __enter__ 函数, 当进入 with 块时, 这个函数被调用, 而它的返回值将作为 as 后引用的值. 一个简单的例子是

Posted at Jun 12 2011 - 11:18:54

Permanent Link: /p/328 Load full text

Post tags:

Exception Handling
Python
RAII

C++ 异常不怎么常见知识点 --- 后传

上一篇后 timothyqiu 同学回复提到通过 std::set_unexpected 指定一个处理方法, 在函数抛出与异常声明不相符的异常时调用. 比如下面这样

#include <stdexcept>
#include <iostream>

void func_throws() throw (std::out_of_range)
{
    throw std::logic_error("danger!");
}

void throw_another()
{
    throw std::out_of_range("safe");
}

int main()
{
    std::set_unexpected(throw_another);
    try {
        func_throws();
    } catch (std::out_of_range e) {
        std::cerr << e.what() << std::endl;
    }
    return 0;
}

有了这个处理函数后, 确实异常被神奇般地抓住了.

不过换个写法, 如果处理函数里面也继续抛 std::logic_error

#include <stdexcept>
#include <iostream>

void func_throws() throw (std::out_of_range)
{
    throw std::logic_error("danger!");
}

void throw_another()
{
    throw std::logic_error("not safe!");
}

int main()
{
    std::set_unexpected(throw_another);
    try {
        func_throws();
    } catch (std::out_of_range e) {
        std::cerr << e.what() << std::endl;
    }
    return 0;
}

    程序照崩.

    也就是说, 处理函数相当于替换原来的函数, 在错误处原地重新抛出一个异常, 但异常必须匹配原来函数的异常声明, 否则异常仍然无法捕捉. 明显扯淡么, 随便找两个异常声明不搭界的函数, 这货不就不管用了么, 总不能随抛随设吧.

    当然, 标准还规定了一个很犀利的异常类型, 叫做 std::bad_exception, 如果把这家伙加进异常声明, 那就给力了

#include <stdexcept>
#include <iostream>

void func_throws() throw (std::out_of_range, std::bad_exception)
{
    throw std::logic_error("danger!");
}

void throw_another()
{
    throw;
}

int main()
{
    std::set_unexpected(throw_another);
    try {
        func_throws();
    } catch (std::bad_exception e) {
        std::cerr << e.what() << std::endl;
    }
    return 0;
}

好了, 原来的异常在 throw_another 里面摇身一变, 成了 std::bad_exception, 不过看 std::cerr 吐出来的东西, 信息都消失了啊, 这不是坑爹么.
其实说到底, 这跟写成

void throw_another()
{
    throw std::bad_exception("std::bad_exception");
}

Posted at Apr 14 2011 - 14:35:07

Permanent Link: /p/275 Load full text

Post tags:

C++
Exception Handling

C++ 异常不怎么常见知识点

    之前也反复有人推荐 Google 的 C++ Coding Style, 昨天看到一位老师写的解读 Google C++ code style 谈对 C++ 的理解, 文后的讨论大多集中在 Google 不允许 C++ 异常. 我这里就不多插嘴了, 不过有些关于异常的基本情况还是想略聊一聊.
    文中的例子使用 g++ 4.5.2 和 clang++ 2.9 编译测试通过.

    如果一个函数声明了异常声明与该函数实际抛出的异常不匹配, 那么这个异常不会被捕获到. 也就是说 catch (...) 不是银弹.

#include <stdexcept>

void func_throws() throw (std::out_of_range)
{
    throw std::logic_error("danger!");
}

int main()
{
    try {
        func_throws();
    }
    catch (std::out_of_range) {}
    catch (std::logic_error) {}
    catch (...) {}
    return 0;
}

    补丁: std::set_unexpected 函数与不预期的异常

    而一个有趣的 C++ 规定是, 如果一个函数没有任何异常声明, 则该函数有可能抛出任何异常. 这个规定的一个隐喻是, 一切 C 函数都有可能抛出任何异常. 虽然 C 连异常是什么都不知道, 不过没关系. 因为 C 函数是异常透明的.
    比如下面的例子

#include <stdexcept>

extern "C" void exception_pass();

void func_throws()
{
    throw std::logic_error("danger!");
}

void upper_cpp_func()
{
    exception_pass();
}

int main()
{
    try {
        upper_cpp_func();
    } catch (std::logic_error) {
        return 0;
    }
    return 1;
}

extern "C" void exception_pass()
{
    func_throws();
}

在异常发生后的 stack unwind 阶段, C 函数调用栈帧与 C++ 函数栈帧的处理方式相同. 执行结果是一样的. 但这并不意味着一种好的 C/C++ 编程方式, C 是没有 RAII 的!
另外, 分离编译再链接时行为会不同, 可能出现异常无法被捕获的情况.

Posted at Apr 11 2011 - 13:42:28

Permanent Link: /p/256 Load full text

Post tags:

Exception Handling
C
C++

C++ 中捕获整数除零错误

继承自 C 的优良传统, C++ 也是一门非常靠近底层的语言, 可是实在是太靠近了, 很多问题语言本身没有提供解决方案, 可执行代码贴近机器, 运行时没有虚拟机来反馈错误, 跑着跑着就毫无征兆地崩溃了, 简直比过山车还刺激.
虽然 C++ 加入了异常机制来处理很多运行时错误, 但是异常机制的功效非常受限, 很多错误还没办法用原生异常手段捕捉, 比如整数除 0 错误. 下面这段代码

#include <iostream>

int main()
{
    try {
        int x, y;
        std::cin >> x >> y;
        std::cout << x / y << std::endl;
    } catch (...) {
        std::cerr << "attempt to divide integer by 0." << std::endl;
    }
    return 0;
}

输入 "1 0" 则会导致程序挂掉, 而那对 try-catch 还呆在那里好像什么事情都没发生一样. 像 Python 一类有虚拟机环境支持的语言, 都会毫无悬念地捕获除 0 错误.

使用信号

    不过, 底层自然有底层的办法. 这得益于硬件体系中的中断机制. 简而言之, 当发生整数除 0 之类的错误时, 硬件会触发中断, 这时操作系统会根据上下文查出是哪个进程不给力了, 然后给这个进程发出一个信号. 某些时候也可以手动给进程发信号, 比如恼怒的用户发现某个程序卡死的时候果断 kill 掉这个进程, 这也是信号的一种.
    这次就不是 C 标准了, 而是 POSIX 标准. 它规定了哪些信号进程不处理也不会有太大问题, 有些信号进程想处理也是不行的, 还有一些信号是错误中断, 如果程序处理了它们, 那么程序能继续执行, 否则直接杀掉.
    不过, 这些错误处理默认过程都是不存在的, 需要通过调用 signal 函数配置. 方法类似下面这个例子

#include <csignal>
#include <cstdlib>
#include <iostream>

void handle_div_0(int)
{
    std::cerr << "attempt to divide integer by 0." << std::endl;
    exit(1);
}

int main()
{
    if (SIG_ERR == signal(SIGFPE, handle_div_0)) {
        std::cerr << "fail to setup handler." << std::endl;
        return 1;
    }
    int x, y;
    std::cin >> x >> y;
    std::cout << x / y << std::endl;
    return 0;
}

可以看出, signal 接受两个参数, 分别是信号编号和信号处理函数. 成功设置了针对 SIGFPE (吐槽: 为什么是浮点异常 FPE 呢?) 的处理函数 handle_div_0, 如果再发生整数除 0 的惨剧, handle_div_0 就会被调用.
handle_div_0 的参数是信号码, 也就是 SIGFPE, 忽略它也行.

底层机制

Posted at Jul 24 2010 - 13:17:37

Permanent Link: /p/100 Load full text

Post tags:

POSIX
C
Exception Handling
Signal
C++

C++ 对象构造时的异常与 RAII 的救赎在上一篇文章中简单介绍了一下 RAII 的原理, 举了个读文件的例子. 这个例子稍微单薄了一些, 它只封装了一个需要 RAII 机制管理的资源 (`FILE`). 软件工程中流行的观念是, 不具备扩展性, 经不起追加功能的东西注定会悲剧. 现在假如需要给这货增加个缓冲区, 也许这样是可以的 struct File { File(char const filename, int buffer_size) : file(fopen(filename, "r")) , buffer(new char[buffer_size]) { if (NULL == file) { throw std::runtime_error(std::string("fail to open ") + filename); } } ~File() { fclose(file); delete[] buffer; } private: FILE* file; char* buffer; /* other members / }; 在 `buffer` 分配失败时, 一般会抛出 `std::bad_alloc`. 这个类型的破绽相当多, 稍不注意就有可能漏资源. 首先是刚刚提到的 `buffer` 分配失败抛异常, 那么假如这个时候 `file` 已经打开成功了, 它会被关闭么? 其次, 假设 `buffer` 成功分配, 但这时 `file` 打开失败, 那么 `buffer` 是否会被释放呢? 很不幸的, 两者的答案都是否. 还是那句话, 因为 `File` 的构造函数没有走完, 这时抛出异常, 那么析构函数不会被执行. 因此, 不要尝试构造控制多于一个资源的类型. 而遇到这种需求, 应该拆分资源, 然后将这些单元类型进行聚合, 如 struct File { explicit File(char const filename) : file(fopen(filename, "r")) { if (NULL == file) { throw std::runtime_error(std::string("fail to open ") + filename); } } ~File() { fclose(file); } private: FILE* file; /* other members / }; struct Buffer { explicit Buffer(int buffer_size) : buffer(new char[buffer_size]) {} ~Buffer() { delete[] buffer; } private: char buffer; /* other members / }; struct BufferedFile { BufferedFile(char const filename, int buffer_size) : file(filename) , buffer(buffer_size) {} File file; Buffer buffer; /* other members */ }; Posted at Jun 21 2011 - 13:27:55 Permanent Link: /p/363 Load full text	Post tags: RAII Exception Handling C++
从 Python 的 `with` 到 RAII 在上一篇文章中提到了 Python 的 `with` 结构, 其背后的思想正是 RAII. 在 C++ 中, RAII 的样子看起来跟 Python 中的会非常不一样, 还是以打开读取文件为例子 #include <cstdio> #include <stdexcept> #include <iostream> struct File { explicit File(char const* filename) : f(fopen(filename, "r")) { if (NULL == f) { throw std::runtime_error(std::string("fail to open ") + filename); } } std::string readLine() { char buffer[256] = { 0 }; // just for demo if (NULL == fgets(buffer, 256, f)) { if (!feof(f)) { throw std::runtime_error("error occurs while reading file"); } throw std::out_of_range("end of file") } return buffer; } ~File() { fclose(f); } private: FILE* const f; }; int main() { try { File file("litsu"); while (true) { std::cout << file.readLine(); } } catch (std::runtime_error e) { std::cerr << e.what() << std::endl; } catch (std::out_of_range) {} return 0; } 注意看 `try` 块中间的语句, 看起来流程很清晰, 完全不像 Python 里面那样, 还要弄个 `with` 块, 多一级缩进. 都说 C++ 代码没 Python 的精神, 然而在这种小地方 C++ 反而超过了 Python 呢. 其实, Python 的 `with` 块更像个语法糖, 上篇文章中有提到, 双层 `try` 在 Python 中能等效地解决这个问题, 只是看起来丑很多. 这个问题的根本在于, Python 这样不具备 RAII 特性的语言没能处理好对象从不可用状态切换到可用状态的状态过渡. 回顾一下双层 `try` 结构的处理方式 `def readFile(): try: f = open('sawako', 'r') pass try: process(f.readlines()) except: print 'error occurs while reading file' finally: f.close() except: print 'error occurs while reading file'` Posted at Jun 20 2011 - 08:43:07 Permanent Link: /p/358 Load full text	Post tags: Exception Handling C++ RAII Python
Python: `try` `finally` `with` 简介用 Python 做一件很平常的事情: 打开文件, 逐行读入, 最后关掉文件; 进一步的需求是, 这也许是程序中一个可选的功能, 如果有任何问题, 比如文件无法打开, 或是读取出错, 那么在函数内需要捕获所有异常, 输出一行警告并退出. 代码可能一开始看起来是这样的 `def read_file(): try: f = open('yui', 'r') print ''.join(f.readlines()) except: print 'error occurs while reading file' finally: f.close()` 不过这显然无法运作, 因为 `f` 是在 `try` 块中定义的, 而在 `finally` 中无法引用. 如果将 `f` 提取到 `try` 块外部, 如 `def read_file(): f = open('azusa', 'r') try: print ''.join(f.readlines()) except: print 'error occurs while reading file' finally: f.close()` 那么, 问题在于当打开文件失败, 抛出异常将不会被捕获. 挫一点的方法自然是, 再套一层 `try` 吧 `def read_file(): try: f = open('sawako', 'r') try: print ''.join(f.readlines()) except: print 'error occurs while reading file' finally: f.close() except: print 'error occurs while reading file'` 当然这不仅仅是多一层缩进挫了, 连警告输出都白白多一次呢. 正规一点的方式是, 使用 Python 引入的 `with` 结构来解决, 如 `def readFile(): try: with open('mio', 'r') as f: print ''.join(f.readlines()) except: print 'error occurs while reading file'` 当文件打开失败时, 异常自然会被 `except` 到; 否则, 在 `with` 块结束之后, 打开的文件将自动关闭. 除了打开文件, 还有其它这样可以用于 `with` 的东西么? 或者说, 怎么自定义一个什么东西, 让它能用于 `with` 呢? 直接回答后一个问题吧, 秘密在于 Python 虚拟机在 `with` 块退出时会去寻找对象的 `__exit__` 方法并调用它, 把释放资源的动作放在这个 `__exit__` 函数中就可以了; 另外, 对象还需要一个 `__enter__` 函数, 当进入 `with` 块时, 这个函数被调用, 而它的返回值将作为 `as` 后引用的值. 一个简单的例子是 Posted at Jun 12 2011 - 11:18:54 Permanent Link: /p/328 Load full text	Post tags: Exception Handling Python RAII
C++ 异常不怎么常见知识点 --- 后传上一篇后 timothyqiu 同学回复提到通过 `std::set_unexpected` 指定一个处理方法, 在函数抛出与异常声明不相符的异常时调用. 比如下面这样 `#include <stdexcept> #include <iostream> void func_throws() throw (std::out_of_range) { throw std::logic_error("danger!"); } void throw_another() { throw std::out_of_range("safe"); } int main() { std::set_unexpected(throw_another); try { func_throws(); } catch (std::out_of_range e) { std::cerr << e.what() << std::endl; } return 0; }` 有了这个处理函数后, 确实异常被神奇般地抓住了. 不过换个写法, 如果处理函数里面也继续抛 `std::logic_error` `#include <stdexcept> #include <iostream> void func_throws() throw (std::out_of_range) { throw std::logic_error("danger!"); } void throw_another() { throw std::logic_error("not safe!"); } int main() { std::set_unexpected(throw_another); try { func_throws(); } catch (std::out_of_range e) { std::cerr << e.what() << std::endl; } return 0; }` 程序照崩. 也就是说, 处理函数相当于替换原来的函数, 在错误处原地重新抛出一个异常, 但异常必须匹配原来函数的异常声明, 否则异常仍然无法捕捉. 明显扯淡么, 随便找两个异常声明不搭界的函数, 这货不就不管用了么, 总不能随抛随设吧. 当然, 标准还规定了一个很犀利的异常类型, 叫做 `std::bad_exception`, 如果把这家伙加进异常声明, 那就给力了 `#include <stdexcept> #include <iostream> void func_throws() throw (std::out_of_range, std::bad_exception) { throw std::logic_error("danger!"); } void throw_another() { throw; } int main() { std::set_unexpected(throw_another); try { func_throws(); } catch (std::bad_exception e) { std::cerr << e.what() << std::endl; } return 0; }` 好了, 原来的异常在 `throw_another` 里面摇身一变, 成了 `std::bad_exception`, 不过看 `std::cerr` 吐出来的东西, 信息都消失了啊, 这不是坑爹么. 其实说到底, 这跟写成 `void throw_another() { throw std::bad_exception("std::bad_exception"); }` Posted at Apr 14 2011 - 14:35:07 Permanent Link: /p/275 Load full text	Post tags: C++ Exception Handling
C++ 异常不怎么常见知识点之前也反复有人推荐 Google 的 C++ Coding Style, 昨天看到一位老师写的解读 Google C++ code style 谈对 C++ 的理解, 文后的讨论大多集中在 Google 不允许 C++ 异常. 我这里就不多插嘴了, 不过有些关于异常的基本情况还是想略聊一聊. 文中的例子使用 g++ 4.5.2 和 clang++ 2.9 编译测试通过. 如果一个函数声明了异常声明与该函数实际抛出的异常不匹配, 那么这个异常不会被捕获到. 也就是说 `catch (...)` 不是银弹. `#include <stdexcept> void func_throws() throw (std::out_of_range) { throw std::logic_error("danger!"); } int main() { try { func_throws(); } catch (std::out_of_range) {} catch (std::logic_error) {} catch (...) {} return 0; }` 补丁: `std::set_unexpected` 函数与不预期的异常而一个有趣的 C++ 规定是, 如果一个函数没有任何异常声明, 则该函数有可能抛出任何异常. 这个规定的一个隐喻是, 一切 C 函数都有可能抛出任何异常. 虽然 C 连异常是什么都不知道, 不过没关系. 因为 C 函数是异常透明的. 比如下面的例子 `#include <stdexcept> extern "C" void exception_pass(); void func_throws() { throw std::logic_error("danger!"); } void upper_cpp_func() { exception_pass(); } int main() { try { upper_cpp_func(); } catch (std::logic_error) { return 0; } return 1; } extern "C" void exception_pass() { func_throws(); }` 在异常发生后的 stack unwind 阶段, C 函数调用栈帧与 C++ 函数栈帧的处理方式相同. 执行结果是一样的. 但这并不意味着一种好的 C/C++ 编程方式, C 是没有 RAII 的! 另外, 分离编译再链接时行为会不同, 可能出现异常无法被捕获的情况. Posted at Apr 11 2011 - 13:42:28 Permanent Link: /p/256 Load full text	Post tags: Exception Handling C C++
C++ 中捕获整数除零错误继承自 C 的优良传统, C++ 也是一门非常靠近底层的语言, 可是实在是太靠近了, 很多问题语言本身没有提供解决方案, 可执行代码贴近机器, 运行时没有虚拟机来反馈错误, 跑着跑着就毫无征兆地崩溃了, 简直比过山车还刺激. 虽然 C++ 加入了异常机制来处理很多运行时错误, 但是异常机制的功效非常受限, 很多错误还没办法用原生异常手段捕捉, 比如整数除 0 错误. 下面这段代码 `#include <iostream> int main() { try { int x, y; std::cin >> x >> y; std::cout << x / y << std::endl; } catch (...) { std::cerr << "attempt to divide integer by 0." << std::endl; } return 0; }` 输入 "1 0" 则会导致程序挂掉, 而那对 try-catch 还呆在那里好像什么事情都没发生一样. 像 Python 一类有虚拟机环境支持的语言, 都会毫无悬念地捕获除 0 错误. 使用信号不过, 底层自然有底层的办法. 这得益于硬件体系中的中断机制. 简而言之, 当发生整数除 0 之类的错误时, 硬件会触发中断, 这时操作系统会根据上下文查出是哪个进程不给力了, 然后给这个进程发出一个信号. 某些时候也可以手动给进程发信号, 比如恼怒的用户发现某个程序卡死的时候果断 kill 掉这个进程, 这也是信号的一种. 这次就不是 C 标准了, 而是 POSIX 标准. 它规定了哪些信号进程不处理也不会有太大问题, 有些信号进程想处理也是不行的, 还有一些信号是错误中断, 如果程序处理了它们, 那么程序能继续执行, 否则直接杀掉. 不过, 这些错误处理默认过程都是不存在的, 需要通过调用 `signal` 函数配置. 方法类似下面这个例子 `#include <csignal> #include <cstdlib> #include <iostream> void handle_div_0(int) { std::cerr << "attempt to divide integer by 0." << std::endl; exit(1); } int main() { if (SIG_ERR == signal(SIGFPE, handle_div_0)) { std::cerr << "fail to setup handler." << std::endl; return 1; } int x, y; std::cin >> x >> y; std::cout << x / y << std::endl; return 0; }` 可以看出, `signal` 接受两个参数, 分别是信号编号和信号处理函数. 成功设置了针对 `SIGFPE` (吐槽: 为什么是浮点异常 `FPE` 呢?) 的处理函数 `handle_div_0`, 如果再发生整数除 0 的惨剧, `handle_div_0` 就会被调用. `handle_div_0` 的参数是信号码, 也就是 `SIGFPE`, 忽略它也行. 底层机制 Posted at Jul 24 2010 - 13:17:37 Permanent Link: /p/100 Load full text	Post tags: POSIX C Exception Handling Signal C++

	Back to Bit Focus
	NijiPress - Copyright (C) Neuron Teckid @ Bit Focus
	About this site

Bit Focus

使用信号

底层机制