库应该记录错误还是传播错误?
摘要
讨论库是否应该自行记录错误还是将错误传播给调用应用程序的争论,突出展示了不同生态系统(如Go的slog)中的不同实践。
<p>我之前的假设一直是:应用程序记录日志(并处理错误),而库只返回错误。</p>
<p>今天,我<em>震惊地</em>得知,各种生态系统都喜欢在库中记录日志(以至于静默这些日志甚至是一项重要任务)。我对日志的看法一直围绕着宽泛的离散事件,或者(对于小规模的个人项目)将错误写入文件。</p>
<p>我特别惊讶地发现,这是设计Go的slog时的一个重要考量,因为你可以轻松地传播和丰富错误……为什么不直接返回错误(然后通过例如将错误添加到日志上下文并重试来处理)?或者在返回的包中传递额外细节?</p>
<p>什么样的工作流程等让这种做法变得可取?我所能想到的只是能够更改日志级别并静默随机的额外信息。</p>
查看缓存全文
缓存时间: 2026/07/14 04:15
# 库应该记录日志还是传递错误?
来源:https://lobste.rs/s/v3avrp/should_libraries_log_propagate_errors
我之前的假设一直是:应用程序负责记录日志(并处理错误),而库只负责传递错误。
今天,我*震惊地*发现,许多生态系统都热衷于在库中记录日志(以至于静默这些日志甚至成了一项重要任务)。我对日志的理解一直是围绕着宽泛的离散事件,或者(对于小型个人项目)将错误写入文件。
我特别惊讶地得知,这在制作 Go 的 slog 时是一个重要的考量因素,因为你完全可以传递并丰富错误信息……为什么不直接传递错误(并在处理时将其添加到日志上下文中再重试)?或者通过返回包传递额外的细节?
什么样的工作流程或场景会使得这种做法更可取?我能想到的唯一好处就是能够更改日志级别并静默掉那些随意的额外信息。
相似文章
Go 中过度的空指针检查
一篇博客文章讨论了 Go 中过度的空指针检查如何可能表明代码不清晰和错误处理实践不佳,主张早期失败并显式建模不可用的依赖。
技能库漂移:诊断与修复自进化LLM技能库中的隐性故障模式
本文识别了'技能库漂移'作为自进化LLM技能库中的一种隐性故障模式,其中无限制的技能积累导致检索退化与性能停滞。它提供了踪迹级诊断及经过验证的治理方案,将MBPP+ hard-100上的pass@1从0.258提升至0.584。
gabime/spdlog
spdlog 是一个快速的、仅头文件或已编译的 C++ 日志库,支持多种输出目标(sinks)、异步模式以及自定义格式化。它被广泛使用,并可通过主流包管理器获取。
如何编写共享库(2011)
Ulrich Drepper 于 2011 年撰写的经典参考文献《如何编写共享库》,涵盖了 Linux 平台上的 ELF、ABI、符号版本控制以及动态链接的最佳实践。这是一篇被 Linux 开发者广泛引用的系统编程基础性文档。
Rust错误处理的新视角
本文讨论了Rust中不同的错误处理模式,包括panic、使用Option和Result、以及默认恢复机制,并提出了一种超越简单传播或恢复的错误处理方法。