Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020) • Hacker News Board

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#201

Post by safarimonkey » Tue, Feb 23, 2021, 10:38 AM UTC

pedrocr wrote: post #104

johnsoft wrote: post #97

Earlier quoted context omitted.

I found a crate that claims to do #1: https://github.com/dtolnay/no-panic This also looks interesting: https://github.com/Technolution/rustig

Yep, the no-panic crate is the hack I mentioned. It's using the linking process to fail compilation if I remember correctly. It only works on individual functions. rustig I didn't know and looks very interesting, thanks. Having it integrated in the compiler as annotations and guarantees would be ideal.

Here is one (recently created) that operates on the whole program rather than a single function: https://crates.io/crates/no-panics-whatsoever

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#202

Post by safarimonkey » Tue, Feb 23, 2021, 10:46 AM UTC

Subsentient wrote: post #8

For the mostpart, Rust error handling is okay. What really rustles my jimmies, however, is the often mandatory indentation because of a lack of an inverse "if let". I prefer to bail out of a block if a condition is NOT met, rather than execute another nested block if it IS met. Rust makes that harder than it should be. It's good code hygiene in every other language, and Rust makes it painful in places. I've even been…

I ran into this the other day, and it took me a moment to realise that I could just use `matches!`:

    // want to do this
    if not let Some("pattern") = val {
        doSomething();
    }

    // can instead do
    if !matches!(val, Some("pattern")) {
        doSomething();
    }

edit: formatting

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#203

Post by rklaehn » Sat, Feb 27, 2021, 8:43 AM UTC

edflsafoiewq wrote: post #88

unrealhoang wrote: post #48

Earlier quoted context omitted.

anyhow with ? is even shorter than unwrap. If it’s likely to have error at some point, I’d throw in a .context, it is so convenient. Edit: typo.

? requires the return type be annotated with an error type and the success case be annotated with Ok, for all functions up the stack, between the current function and where handling occurs. unwrap is purely local.

I somehow still prefer ?, even in places where unwrap would be perfectly fine, like tests. unwrap is somehow unpleasant to look at.

E.g. you can have tests that return an anyhow::Result, and use ? anywhere in the test. The test will fail if the result is not Ok(()).

Sure, you have the additional boilerplate of the return type annotation and the final Ok(()), but the test logic itself reads nicer, I think.

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#204

Post by sensitive-ears » Mon, Mar 01, 2021, 11:12 PM UTC

simiones wrote: post #200

sensitive-ears wrote: post #174

Earlier quoted context omitted.

The "?" operator doesn't turn them into exceptions, it's just a "return-early-if-error" shortcut. The main difference being that the caller still has to handle the error of a function using "?". (even if it's by punting further up the call stack with more "?", which you could argue is exactly how exceptions work, but it is at least explicit in what functions can fail and which don't)

> even if it's by punting further up the call stack with more "?" Yes, this is exactly what I meant. > it is at least explicit in what functions can fail and which don't So is Java with exceptions (at least as long as developers are even slightly disciplined).

Yeah, I think java had the right idea, but the ergonomics didn't turn out great, so they didn't get the buy in they'd hoped for. Having both checked and unchecked exceptions (ie, NPEs) meant it doesn't offer the same safety guarantees as something like rust does. The implementation of exceptions can also have some implications for the runtime, whereas the enum method of error handling allows you to run in very minimal environments and easily see what's going on. (Exceptions could be implemented this way under the hood, but they often aren't)