提问人:UdiM 提问时间:11/14/2023 更新时间:11/15/2023 访问量:66
Errors 与 Logs in rust
Errors vs Logs in rust
问:
关于日志(对于程序员)和错误类型(例如包含失败选项的枚举),这也是我从 c++ 项目中使用的:
日志(如系统日志):
- 是供程序员调试和了解潜在错误——
- 通常包含文件和行号,以指示日志的来源
错误:
- 是指示不同类型故障的独特值
- 代码本身在发生特定错误时具有备用句柄(例如:用户可以捕获错误,用户可以通过重试来处理它)
busy
- 如果 API 在与用户无关的内部逻辑上失败,则返回某种 .这样,您就不会向用户发送不相关的错误类型
InternalError
这里要注意的主要事情是,日志是为了让程序员更好地了解出了什么问题,而错误是为了在发生故障时提供替代解决方案的代码。日志和错误是分开的,不是一回事。
我的问题是关于 rust 错误处理和日志记录。在 rust 中,为了处理错误,我们创建了可能的故障场景的枚举。在大多数情况下,我还需要实现特征(可以缓解,但我仍然必须为每个错误提供一个字符串)。Display
thiserror
有一个错误的字符串背后的想法是什么?是用户应用程序日志吗?是程序员日志吗?
如果是程序员日志,事情对我来说不会加起来:
- 在文章的开头,我描述了为什么日志 != 错误。但在这种情况下,由于我必须为每个错误实现日志,所以我还必须公开宣布我遇到的每个内部错误,这与我之前描述的“错误 3”点相矛盾
- 程序员日志还具有其他信息,例如日志时间戳、文件和行号。我不知道错误中的字符串是否可以包含该信息,但即使有,这样做似乎也是一种奇怪的方式
错误的字符串和错误本身之间的实现是什么?
答:
在文章的开头,我描述了为什么日志 != 错误。但在这种情况下,由于我必须为每个错误实现日志,所以我还必须公开宣布我遇到的每个内部错误,这与我之前描述的“错误 3”点相矛盾
对于库来说,区分不同类型的错误是很重要的。也许这个特定的错误并不重要,可以忽略不计。也许可以重试该操作。也许我们知道如何处理它。图书馆通常会将错误交给他们的调用者,让他们决定如何处理它们。您的错误第 3 点不适用。
然而,在应用中,这确实在很多时候并不重要。在这些情况下,您可以避免定义自定义错误类型的样板,而只使用通用错误类型,例如 Box<dyn Error>
,或本质上“更好”的库,例如 anyhow
或 eyre
)。Box<dyn Error>
至于它们是否代表日志或错误,Rust 中的错误值在某种程度上尝试两者兼而有之。将它们视为错误条件,而不是错误报告。它们表示发生了错误。一些错误。如何处理它 - 这取决于你。你可以记录它(通常使用面向程序员的表示,应该实现哪些错误)和/或你可以将它们报告给用户,告诉他们已经发生的特定错误(通常通过表示,哪些错误也应该实现)或只是作为通用的“发生错误”消息。Debug
Display
评论
Think about them as error conditions, not error reports. They represent that an error has occurred. Some error. What to do with it - this is up to you. You can log it
- 程序员日志通常包含更多数据,如时间戳、文件和发生错误的行。我很难从中建立适当的日志。在我看来,我可以忽略错误的字符串,并自己处理日志记录
anyhow
评论
std::io::Error
Throwable.getMessage()
std::exception::what()
Exception.message; in Javascript