嘿，我来帮你拆解下这个头疼的问题！你遇到的情况其实挺常见的，大概率是第三方库的内部日志或逻辑导致的，咱们一步步分析：

为什么捕获异常后还会输出堆栈跟踪？ #

你用三种方式捕获了异常，但控制台还是先弹出ERROR级别的堆栈跟踪，核心原因是：soco库自己在内部处理异常时，已经用logging模块打印了ERROR日志。你的try/catch只是捕获了异常、阻止了程序崩溃，但库内部已经输出的日志是没法被你的捕获逻辑收回的——也就是说，你看到的堆栈跟踪不是未捕获异常的默认输出，而是库主动打印的日志内容。

为什么移除try/catch后异常会触发两次？ #

结合你提到的异常源码细节，这个问题大概率和soco的内部逻辑有关：

• 可能是你调用的方法带有重试机制：比如库在请求UPnP设备失败后，会自动重试一次，每次重试失败都会抛出SoCoUPnPException，所以你会看到异常被触发两次。
• 也可能是异常在库的不同逻辑分支里被重复抛出：比如一次是在请求处理中抛出，另一次是在回调/状态检查逻辑中再次触发。

具体解决方案 #

1. 过滤soco库的日志输出（最快速解决堆栈跟踪问题） #

既然是库自己打印的ERROR日志，我们直接把soco的日志级别调高，让它别输出这些冗余的ERROR信息就行：

import logging
# 把soco的日志级别设为WARNING，这样它的ERROR日志会被过滤
logging.getLogger('soco').setLevel(logging.WARNING)

之后再运行你的代码，应该就只会看到你自定义的WARNING日志了。

2. 排查库的重试/重复调用逻辑 #

如果异常触发两次影响了你的业务逻辑，你可以：

• 查看你调用的soco方法的官方文档，看看有没有参数可以关闭重试（比如类似retry=False的配置项）。
• 直接查看方法的源码，确认是不是有多次请求或重试的逻辑，调整调用方式避开重复触发的场景。

3. 确认捕获范围是否覆盖所有场景 #

如果异常是从子线程/异步任务里抛出来的，你的外层try/catch可能没覆盖到这些场景。这种情况下，你需要在子线程/异步任务的内部添加捕获逻辑，或者用对应框架的异常处理机制（比如asyncio的try/except包裹协程，或者concurrent.futures的回调处理异常）。

内容的提问来源于stack exchange，提问作者TheMeaningfulEngineer