如何消除“ sys.excepthook丢失”错误？

Question

注意：我没有尝试在Windows或2.7.3以外的Python版本下重现下面描述的问题。

引发问题的最可靠方法是通过:（在之下bash）通过管道传递以下测试脚本的输出：

try:
    for n in range(20):
        print n
except:
    pass

即：

% python testscript.py | :
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr

我的问题是：

__如图所示（在Unix /下bash）运行脚本时， 如何修改上面的测试脚本 以避免错误消息？

（如测试脚本所示，不能用来捕获错误try-except。）

诚然，上面的示例是高度人为的，但是当我的脚本的输出通过某些第三方软件传递时， 有时会 遇到相同的问题。

该错误消息当然是无害的，但是它使最终用户感到不安，因此我想使其静音。

编辑：以下脚本与上面的原始脚本有所不同，仅在于它重新定义了sys.excepthook，其行为与上面给出的完全相同。

import sys
STDERR = sys.stderr
def excepthook(*args):
    print >> STDERR, 'caught'
    print >> STDERR, args

sys.excepthook = excepthook

try:
    for n in range(20):
        print n
except:
    pass

Answer 1

如图所示（在Unix /下bash）运行脚本时，如何修改上面的测试脚本以避免错误消息？

您将需要防止脚本将任何内容写入标准输出。这意味着删除所有print语句和对的任何使用sys.stdout.write以及调用这些语句的任何代码。

发生这种情况的原因是，您正在将来自Python脚本的非零数量的输出传递给从未从标准输入读取的内容。这不是该:命令独有的。您可以通过管道传输到任何不读取标准输入的命令来获得相同的结果，例如

python testscript.py | cd .

再举一个简单的例子，考虑一个脚本，printer.py其中只包含

print 'abcde'

然后

python printer.py | python printer.py

会产生相同的错误。

当将一个程序的输出通过管道传输到另一个程序时，写入程序产生的输出将备份到缓冲区中，并等待读取程序从缓冲区中请求该数据。只要缓冲区是非空的，任何试图关闭写入文件对象的尝试都将因错误而失败。这是您看到的消息的根本原因。

触发错误的特定代码在Python的C语言实现中，这说明了为什么无法使用try/except块捕获该错误：它在脚本内容完成处理后运行。基本上，当Python关闭自身时，它会尝试关闭stdout，但这失败了，因为仍然有缓冲的输出等待读取。因此，Python会尝试像往常一样报告此错误，但sys.excepthook已在完成过程中被删除，因此失败。然后，Python尝试将消息打印到sys.stderr，但该消息已被重新分配，因此再次失败。您在屏幕上看到消息的原因是Python代码确实包含偶然性fprintf
即使Python的输出对象不存在，也可以直接将一些输出写到文件指针中。

对于那些对此过程的细节感兴趣的人，让我们看一下Python解释器的关闭序列，该序列是通过Py_Finalize函数来实现的pythonrun.c。

1. 调用出口挂钩并关闭线程后，完成代码将调用PyImport_Cleanup以完成和取消分配所有导入的模块。此函数执行的倒数第二个任务是删除sys模块，该模块主要包括调用_PyModule_Clear以清除模块字典中的所有条目-特别是包括标准流对象（Python对象）stdout和stderr。
2. 当值是从字典移除或由一个新的值代替，其引用计数被递减使用的Py_DECREF宏。引用计数达到零的对象有资格进行释放。由于sys模块保留了对标准流对象的最后剩余引用，因此当这些引用未设置时_PyModule_Clear，就可以将其释放。1个
3. Python文件对象的重新分配由实现的file_dealloc功能在fileobject.c。首先使用适当命名的函数调用Python文件对象的close方法：close_the_file

   ret = close_the_file(f);
   

对于标准文件对象，close_the_file(f)
委托给Cfclose函数，如果仍有数据要写入文件指针，则C函数设置错误条件。file_dealloc然后检查该错误情况并打印您看到的第一条消息：

    if (!ret) {
    PySys_WriteStderr("close failed in file object destructor:\n");
    PyErr_Print();
}
else {
    Py_DECREF(ret);
}

1. 打印该消息后，Python然后尝试使用显示异常PyErr_Print。委托PyErr_PrintEx并作为其功能的一部分，PyErr_PrintEx尝试从访问Python异常打印机sys.excepthook。

   hook = PySys_GetObject("excepthook");
   

如果在Python程序的正常过程中这样做会很好，但是在这种情况下，sys.excepthook已经清除了。2
Python检查此错误情况，并输出第二条消息作为通知。

    if (hook && hook != Py_None) {
    ...
} else {
    PySys_WriteStderr("sys.excepthook is missing\n");
    PyErr_Display(exception, v, tb);
}

1. 在通知我们有关丢失的信息之后excepthook，Python然后回退到使用来打印异常信息PyErr_Display，这是显示堆栈跟踪的默认方法。此功能所做的第一件事就是尝试访问sys.stderr。

   PyObject *f = PySys_GetObject("stderr");
   

在这种情况下，这将不起作用，因为sys.stderr它已被清除并且无法访问。3因此，代码fprintf直接调用以将第三条消息发送到C标准错误流。

    if (f == NULL || f == Py_None)
    fprintf(stderr, "lost sys.stderr\n");

有趣的是，此行为在Python
3.4+中有所不同，因为完成过程现在在清除内置模块之前会显式刷新标准输出和错误流。这样，如果您有等待写入的数据，则将得到一个错误信号，该信号明确地表明该情况，而不是正常完成过程中的“偶然”故障。另外，如果您跑步

python printer.py | python printer.py

使用Python
3.4（print当然在语句后加上括号），您根本不会遇到任何错误。我想第二次调用Python可能出于某种原因消耗了标准输入，但这是一个完全独立的问题。

1实际上，这是一个谎言。Python的导入机制缓存每个导入模块的字典中的副本，这是不释放，直到_PyImport_Fini运行，后来在执行Py_Finalize，并且
那是 什么时候的标准流对象的最后一个引用消失。一旦引用计数达到零，
就立即Py_DECREF释放对象。但是，对于主要答案而言，最重要的是将引用从模块的字典中删除，然后在以后的某个时间释放。 __sys

2同样，这是因为sys借助属性缓存机制，在真正释放任何内容之前，该模块的字典已被完全清除。您可以运行Python，并带有-vv选项以查看所有模块的属性都未设置，然后获得有关关闭文件指针的错误消息。

3除非您了解前面脚注中提到的属性缓存机制，否则这部分行为是唯一没有意义的部分。