TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Error Stacking in Rust

137 点作者 samanthasu5 个月前

16 条评论

ekimekim5 个月前
Ok, so the original idea of Result&lt;T, Error&gt; was that you have to consider and handle the error at each place.<p>But then people realised that 99% of the time you just want to handle the error by passing it upwards, and so ? was invented.<p>But then people realised that this loses context of where the error occured, so now we&#x27;re inventing call stacks.<p>So it seems that what people actually want is errors that by default get transferred to their caller and by default show the call stack where they occured. And we have a name for that...exceptions.<p>It seems that what we&#x27;re converging towards is really not all that different from checked exceptions, just where the error type is an enum of possible errors (which can be non-exhaustive) instead of a list of possible exception types (which IIUC was the main problem with java&#x27;s checked exceptions).
评论 #42462901 未加载
评论 #42460992 未加载
评论 #42461663 未加载
评论 #42461070 未加载
评论 #42465776 未加载
评论 #42461237 未加载
评论 #42462787 未加载
评论 #42461168 未加载
评论 #42464301 未加载
评论 #42463515 未加载
评论 #42467026 未加载
评论 #42524968 未加载
评论 #42461534 未加载
评论 #42462594 未加载
评论 #42461511 未加载
评论 #42461496 未加载
评论 #42462881 未加载
评论 #42474918 未加载
namjh5 个月前
&gt; Consequently, this also means you cannot define two error variants from the same source type. Considering you are performing some I&#x2F;O operations, you won&#x27;t know whether an error is generated in the write path or the read path. This is also an important reason we don&#x27;t use thiserror: the context is blurred in type.<p>This is true only if you add #[from] attribute to a variant. Implementing std::convert::From is completely optional. Personally I don&#x27;t prefer it too as it ambiguates the context. I only use it for &quot;trivially&quot; wrapped errors like eyre::Report.
评论 #42459269 未加载
dmart5 个月前
Using #[from] in a thiserror enum is an antipattern, IMO. I kind of wish it wasn&#x27;t included at all because it leads people to this design pattern where errors are just propagated upwards without any type differentiation or additional context.<p>You can absolutely have two different enum variants from the same source type. It would look something like:<p><pre><code> #[derive(Debug, Error)] pub(crate) enum MyErrorType { #[error(&quot;failed to create staging directory at {}&quot;, path.display())] CreateStagingDirectory{ source: std::io::Error, path: std::path::PathBuf, }, #[error(&quot;failed to copy files to staging directory&quot;)] CopyFiles{ source: std::io::Error, } } </code></pre> This does mean that you need to manually specify which error variant you are returning rather than just using ?:<p><pre><code> create_dir(path).map_err(|err| MyErrorType::CreateStagingDirectory { source: err, path: path.clone() })?; </code></pre> but I would argue that that is the entire point of defining a specific error type. If you don&#x27;t care about the context and only that an io::Error occurred, then just return that directly or use a type-erased error.
评论 #42464815 未加载
exDM695 个月前
Why does adding `backtrace` to thiserror&#x2F;anyhow require adding debug symbols?<p>You&#x27;ll certainly need it if you want to have human readable source code locations, but doesn&#x27;t it work with addresses only? Can&#x27;t you split off the debug symbols and then use `addr2line` to resolve source code locations when you get error messages from end users running release builds?
评论 #42460654 未加载
评论 #42460522 未加载
k_bx5 个月前
The simplest thing that &quot;just work&quot; for me is replacing ? with .context(h!())? and this macro:<p>#[macro_export]<p>macro_rules! h {<p><pre><code> () =&gt; { concat!(&quot;at &quot;, file!(), &quot; line &quot;, line!(), &quot; column &quot;, column!()) }; </code></pre> and then using anyhow::Result.<p>Solves 99% problems in error handling
lilyball5 个月前
&gt; <i>Then, to be able to translate the stack pointer we will need to include a large debuginfo in our binary. In GreptimeDB, this means increasing the binary size by &gt;700MB (4x compared to 170MB without debuginfo).</i><p>Surely that&#x27;s comparing full debuginfo, right? Backtraces just need symbols, not full debuginfo, and there&#x27;s no way the symbols are 4x the size of the binary.
评论 #42459655 未加载
shepmaster5 个月前
Hey all, I’m the author of SNAFU (mentioned in the article). I’m off to bed now, but I’d be happy to try and answer any questions people might have sometime tomorrow.<p>I’m glad to see SNAFU was useful to others!
评论 #42459802 未加载
joshka5 个月前
It&#x27;s technically feasible to add SpanTrace support to thiserror fairly easily (30 mins work - Issue: <a href="https:&#x2F;&#x2F;github.com&#x2F;dtolnay&#x2F;thiserror&#x2F;issues&#x2F;400">https:&#x2F;&#x2F;github.com&#x2F;dtolnay&#x2F;thiserror&#x2F;issues&#x2F;400</a>, PR: <a href="https:&#x2F;&#x2F;github.com&#x2F;dtolnay&#x2F;thiserror&#x2F;pull&#x2F;401">https:&#x2F;&#x2F;github.com&#x2F;dtolnay&#x2F;thiserror&#x2F;pull&#x2F;401</a>). This would solve part of the problem in a way that is meaningfully good for that side of the ecosystem. I suspect you could probably do something similar for Snafu
评论 #42461446 未加载
Sytten5 个月前
What is really annoying with thiserror is the wizard refusal to give us an easy way to print the error chain. No I dont want to convert it to anyhow just to print the error...
评论 #42458491 未加载
DavidWilkinson5 个月前
Interesting approach! We had a similar journey at HASH to figuring out how we deal with stacked errors (as well as collecting parallel errors), developed the `error-stack` crate to solve for it. It works by abstracting over the boilerplate needed to stack errors by wrapping errors in a `Report`. Each time you change the context (which is equivalent to wrapping an error) the location is saved as well, with optional spantrace and backtrace support. It also supports supplying additional attachments, to enrich errors. We spent quite a bit of time on the user output, as well (both for `Debug` and `Display`) so hopefully the results are somewhat pleasant to work with and read.
gregwebs5 个月前
This seems like a user implement of Zig error return traces: <a href="https:&#x2F;&#x2F;ziglang.org&#x2F;documentation&#x2F;master&#x2F;#Error-Return-Traces" rel="nofollow">https:&#x2F;&#x2F;ziglang.org&#x2F;documentation&#x2F;master&#x2F;#Error-Return-Trace...</a>
samanthasu5 个月前
A good error report is not only about how it gets constructed, but what is more important, to tell what human can understand from its cause and trace. In this example, we analyzed and showed how to design stacked errors and what should be considered in this process.
gfreezy5 个月前
<p><pre><code> async fn handle_request(req: Request) -&gt; Result&lt;Output&gt; { let msg = decode_msg(&amp;req.msg).context(DecodeMessage)?; &#x2F;&#x2F; propagate error with new stack and context verify_msg(&amp;msg)?; &#x2F;&#x2F; pass error to the caller directly process_msg(msg).await? &#x2F;&#x2F; pass error to the caller directly } async fn decode_msg(msg: &amp;RawMessage) -&gt; Result&lt;Message&gt; { serde_json::from_slice(&amp;msg).context(SerdeJson) &#x2F;&#x2F; propagate error with new stack and context } </code></pre> how to capture the virtual stack when `verify_msg` returns an error? Do you have some lint to make sure every error is attached with a context?
评论 #42461504 未加载
carlsverre5 个月前
Inspired by this blog post I just added an `#[implicit]` field feature to the `thiserror` crate. It makes it easy to automatically annotate errors with things like code location (per this blog post), a timestamp, or a backtrace without requiring further modifications to the thiserror crate. I&#x27;m hoping that dtolnay will consider it. You can find my PR here: <a href="https:&#x2F;&#x2F;github.com&#x2F;dtolnay&#x2F;thiserror&#x2F;pull&#x2F;402">https:&#x2F;&#x2F;github.com&#x2F;dtolnay&#x2F;thiserror&#x2F;pull&#x2F;402</a>
zote5 个月前
URL changed, I think: <a href="https:&#x2F;&#x2F;greptime.com&#x2F;blogs&#x2F;2024-05-07-rust-error-handling" rel="nofollow">https:&#x2F;&#x2F;greptime.com&#x2F;blogs&#x2F;2024-05-07-rust-error-handling</a>
dpc_012345 个月前
Probably also worth mentioning: <a href="https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;error-stack" rel="nofollow">https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;error-stack</a>