未被捕获的Python异常是否会导致内存引导或其他问题？

Question

我的团队中有一个论点是内部使用自动化脚本的代码块。

以下函数发出网络请求并返回其获得的结果。

网络请求有时会因IOError而失败，但如果代码重试，它将能够连接并再次获得结果。所以代码有一个重试机制来处理这样的错误。

但有时会发生其他错误（例如，超时等）。从需求的角度来看，我们应该使用错误代码退出脚本来解决这些问题，这样调用程序就会知道脚本出了问题，并且告诉工程师让他们来处理它。

这是代码：

def my_func():
    retry_times = 5
    sleep_time = 5
    for i in range(0, 6)
        try:
            result = network_request()
            break
        except IOError as err:
            if i == retry_times:
                log.error
                raise
            else:
                log.warning("Request failed, sleep %s seconds and retry <%s/%s>"
                            % (sleep_time, i, retry_times))
    return result

但我们的团队成员之一认为我们应该捕获所有剩余的异常，永远不要将异常抛到最外面的代码，最后让脚本退出并显示错误代码并打印堆栈跟踪打印。

他将此称为“异常泄漏”，这违反了常见的编码规则。这里是他的代码（带有“＃Added code line”的行是更改的行）：

def my_func():
    retry_times = 5
    sleep_time = 5
    for i in range(0, 6)
        try:
            result = network_request()
            break
        except IOError as err:
            if i == retry_times:
                log.error
                raise
            else:
                log.warning("Request failed, sleep %s seconds and retry <%s/%s>"
                            % (sleep_time, i, retry_times))
        except Exception:  # Added code line
            log.error("Error happened: %s" % err)  # Added code line
            exit(1)
    return result

我说他正在做Python刚刚做过的事情：

1. 打印错误日志。
2. 使用非零退出代码存在脚本

但他认为“你怎么知道Python在捕获异常时什么都没做？”，“留下未捕获的异常会导致内存泄漏”，“任何设计良好的程序都不会将未捕获的异常留到最后，这是常识”。

这让我很困惑，因为我从来没有听说过这种“常识”，特别是对于Python（不确定C ++是否有这种“常识”）。我用Google搜索了主题，发现甚至没有人问过这样的问题。我从一开始就知道异常处理的原则是：

1. 处理代码能够处理的异常。
2. 如果您无法处理，则将这些异常提升到外部范围。

在这种情况下，由于此脚本是内部使用自动化脚本，当发生此类问题时，打印详细信息堆栈跟踪并使用非零错误代码退出脚本正是我们想要的，因为代码无法处理此类问题所以它应该最后向工程师提出这个问题。

添加捕获未知异常的行，打印错误日志，然后使用非零错误代码退出脚本，例如冗余地执行已完成的操作。

所以我在这里问：1。“将未捕获的异常留到最后并最终导致脚本退出”导致任何问题，如“内存泄漏”或其他问题？ 2. Python编码规则中是否存在任何此类“常识”，以至于不会将任何未捕获的异常留到最后，提供“打印错误日志”和“以非零代码退出”正是脚本想要做的事情。

Answer 1

这取决于您的其他代码。许多框架（如Django）都有一个设置变量DEBUG。如果设置为true，将公开相关数据。如果没有用户显示404错误。

如果您使用linter，它会告诉您捕获未指定的异常是一种不好的做法