[HN Gopher] More than you've ever wanted to know about errors in...
___________________________________________________________________
More than you've ever wanted to know about errors in Rust (2022)
Author : asymmetric
Score : 69 points
Date : 2023-07-22 13:20 UTC (9 hours ago)
(HTM) web link (www.shuttle.rs)
(TXT) w3m dump (www.shuttle.rs)
| Diggsey wrote:
| > However in Rust, panics cannot be recovered from, there is no
| way to incept a panic in the current thread.
|
| You definitely can: https://doc.rust-
| lang.org/std/panic/fn.catch_unwind.html
| loeg wrote:
| As sibling alludes to, there is no guarantee that panic unwinds
| the stack. It can just abort immediately.
| burntsushi wrote:
| Yes, that's what the docs linked say. And the GP is correct
| in saying "you definitely can." The GP is a correction to the
| article which incorrectly states that "there is no way to
| incept [sic] a panic in the current thread." The correct
| phrasing would be "there is no way to _guarantee_ that you
| can recover from a panic in the current thread. "
|
| In the context of the article, this is a somewhat minor
| point. Because you can't guarantee the recovery from panics,
| you often code _as if_ you can never recover from panics. And
| thus, when you write code that _can_ panic (for example,
| `slice[i]`), it 's best to conservatively assume that any
| such panic won't be recovered from. Still though, the
| existence of a recovery mechanism can be useful advice in
| some circumstances: https://docs.rs/regex/1.*/regex/#panics
|
| The broader story here is a knot that is difficult to
| untangle because 1) people have different values and 2) words
| mean different things to different people. I tried to
| untangle some part of it here (although it's more broad than
| just "panics can or can't be recovered from," it's still all
| connected): https://blog.burntsushi.net/unwrap/
| Groxx wrote:
| To extend on this: _application_ developers can actually
| guarantee it, because they control the compilation process,
| which is what decides if it aborts or not. Libraries have
| less control / no guarantee.
| littlestymaar wrote:
| > To extend on this: application developers can actually
| guarantee it, because they control the compilation
| process, which is what decides if it aborts or not.
|
| They can control that panic isn't compiled as abort, but
| even then, if there's a destructor that can panic, then
| if it panics during unwinding, it aborts. So even the app
| developer cannot guarantee to catch all panics.
| burntsushi wrote:
| That's right, but it doesn't give you a guarantee in
| every sense of the word. A panic during unwinding will
| still result in an abort.
| RichieAHB wrote:
| This is true for unwinding but from the Notes section on the
| linked page, panics can't be caught using that function if the
| panic aborts the process.
| mmastrac wrote:
| If you're writing library code and you are new to rust, just
| stick with `thiserror` and nest your error types (ie: have lower-
| level errors wrapped up in higher-level errors using #[from]).
| It's barely more effort than using the Any* error types and the
| benefits of having concrete errors greatly outweigh the tiny bit
| of extra effort.
| jmakov wrote:
| No mention of error-stack?
| troupo wrote:
| I find the concept of unrecoverable panics extremely weird.
| Crashing your entire program just because something unexpected
| happened? Erlang would lime a word with you :)
| Galanwe wrote:
| Well not every program has to be a super robust daemon
| recovering from any kind of problem.
|
| There's a good bunch of programs that are just supposed to read
| some inputs, perform a task and crash with an error message and
| exit code if anything goes wrong.
| amitu wrote:
| This is not fair summary of the situation. Panics can be
| "caught", most Rust web framework will catch panic when
| handling a http request and return 500, leaving other requests
| unaffected (more or less). This is almost no different from
| Python, Java, even Erlang.
|
| Panic is a way for Rust library ecosystem to signal this error
| in un-recoverable, and is probably a bug in program, for which
| you would be happy getting Sentry or some such reporting.
|
| Most errors in Rust are handled using mechanisms described in
| post using Result. Some, this is probably a bug in code,
| mechanism should be present in other languages.
|
| There are even efforts to make code that can panic detectable
| at compile time, https://docs.rs/no-panic/latest/no_panic/
| jjnoakes wrote:
| > unrecoverable panics
|
| Panics are recoverable.
| saurik wrote:
| FWIW, the article incorrectly but explicitly and repeatedly
| states that panics are not recoverable, and so this is a
| gripe with the content causing misinformation.
| steveklabnik wrote:
| It's not really a misconception exactly. They are to be
| used for unrecoverable errors, conceptually. Because of
| this, the ecosystem tends to treat them as such, even if
| you can choose to require the ability to catch them, just
| as if you can also require the ability _not_ to catch them,
| which is one of the reasons why the ecosystem follows the
| rule: they can't rely on the behavior (unless they want to
| limit their audience and that's basically never worth it).
| nrabulinski wrote:
| You cannot catch a panic, only an unwind. And you
| shouldn't assume that your panic will unwind as a
| downstream user of your crate can just as easily change
| panics to aborts
| codetrotter wrote:
| It's a nice summary about error handling in Rust, but doesn't
| present anything new for anyone who has been writing Rust for a
| while.
|
| The title "more than you've ever wanted to know about errors in
| Rust" had me expecting to learn something new.
|
| Still a nice intro though, and could for example form part of the
| documentation for shuttle in the future, to help people who are
| new to Rust get into using shuttle.
| deagle50 wrote:
| Yea this should be called "The minimum you need to know about
| errors in Rust". These click bait self promotion blog post
| titles are getting out of hand.
| pvsnp wrote:
| I agree. This would've likely saved me a lot of time that was
| spent on trial and error but now it's not new. But this is
| great reference to forward to new folks getting started.
| sshine wrote:
| Yes, nice intro to errors, and nothing new.
|
| I would have liked a small conclusion under the chapter that
| names thiserror, anyhow and eyre, arguing why you might pick
| one library over another, and which one to pick if you don't
| have any requirements (anyhow). This blog post compares the two
| first with examples on when they're neat and cumbersome:
|
| https://www.shakacode.com/blog/thiserror-anyhow-or-how-i-han...
| epage wrote:
| I appreciated the approach in
| https://sabrinajewson.org/blog/errors
| pducks32 wrote:
| When I first used Rust, I was using failure and it just made
| sense to me. And then we got the 2nd (3rd?) wave of error
| libraries and nothing has ever made simple sense to me since.
| Never saw this link and it's wonderful, it's exactly how I
| think of errors. Thanks!
| Dowwie wrote:
| The Error rabbit hole goes far deeper than this. I was hoping to
| read about downcasting and anti-patterns. What were others
| looking for?
| littlestymaar wrote:
| Same, this is barely "an introduction to Rust error handling in
| 2023"
| ezekiel68 wrote:
| I was very happy to see a recap of all the basics. Sometimes,
| with new crates coming and going, I worry/imagine I may be
| falling behind on the latest "rustic" ways to handle certain
| things like this.
| mike_hock wrote:
| TL;DR: It's Java's explicit throw declarations with extra steps,
| and syntactic sugar to make the totally-not-exceptions work kinda
| like exceptions.
| pornel wrote:
| It does feel like checked exceptions. But the subtle but
| important thing is that results are not control flow
| constructs. They're just values with syntax sugar, so all other
| language features work with them (you can store, modify, nest,
| pass them without try/catch/throw constructs)
| mike_hock wrote:
| It's not subtle in that it's not opaque to the programmer
| that it's just a "regular" sum type
|
| It's not important in that it doesn't change what the
| programmer can do with it, it just changes the syntax used.
|
| Return an error: return Err(...) vs. throw ...
|
| Propagate error to caller: ? vs. nothing
|
| Store/modify/nest/pass: Without try/catch/throw construct vs.
| WITH try/catch/throw construct.
|
| The much more important difference is between bounded vs.
| unbounded error types. Rust falls in the former camp and
| inherits all the problems (and benefits) that come with it.
| pornel wrote:
| I'm not sure what you mean by bounded. There's `dyn Error`
| that lets you unify all error types. You can also make
| functions generic over the error type.
|
| Places where people use precise concrete error types are
| not forced by the language, it's just the best practice for
| libraries.
| milliams wrote:
| *[2022]
___________________________________________________________________
(page generated 2023-07-22 23:01 UTC)