Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

msirringhaus.github.io

Post reply on HN
Print view View original

41–50 of 204 posts

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

#41

Post by gardaani »

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 totally agree. I love Swift's guard let. It makes early returning [1] easy:

    guard let value = optvalue else {
        return // optvalue is none
    }
There has been several proposals [2][3] to fix it in Rust but they don't seem to go anywhere.

I'm using this in my own code now to unwrap or return (it looks stupid):

        let value = if let Some(value) = optvalue {
            value
        } else { // optvalue is none
            return;
        };
[1] https://szymonkrajewski.pl/why-should-you-return-early/

[2] https://github.com/rust-lang/rfcs/issues/2616

[3] https://github.com/rust-lang/rfcs/pull/1303

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

#42

Post by exrook »

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'm confused, have you found the try operator ("?") insufficient for your use cases? I believe it does what you are describing, ex:

    fn process_file(p: Path) -> Result {
        let file = File::open(p)?; //Return err if file can't be opened
        let mut out = String::new();
        file.read_to_string(&mut out)?; // Return err if read fails
        out
    }
If you want to handle the error case within the same function `try` blocks are available in nightly[0] and will eventually come to stable[1]

[0] https://doc.rust-lang.org/nightly/unstable-book/language-fea...

[1] https://github.com/rust-lang/rust/issues/31436

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

#43

Post by nerdponx »

why_Mr_Anderson wrote: post #20
kstenerud wrote: post #4

Error handling has been wrong since the beginning, and has continued to be wrong ever since. First, we had error codes. Except these were wrong because people forget all the time to check them. Then we had exceptions, which solved the problem of people forgetting to check by crashing the app. Then the Java team got the bright idea to have checked exceptions, which at first helped to mitigate crashes from uncaught exc…

Because all systems try to handle several kinds of unexpected behavior in the exactly the same way - invalid arguments (e.g. 'x == null') - code logic (e.g. 'if (x.salary I'd argue that only the 3rd kind is actually 'exception', it's completely out of program's control. Code contracts are wonderful way of dealing with 1st and 2nd kind, sadly they didn't catch up and remains mostly unknown. They are vastly superior to…

Unless you have dependent types, isn't a contract just syntactic sugar for an if/else that either raises and exception or returns an error code?

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

#44

Post by jgilias »

da-x wrote: post #40
jgilias wrote: post #16

The rule of thumb for me is `thiserror` for libraries, `anyhow` for executables. Seems to work well enough in the vast majority of cases. I do agree that the Rust way can be frustrating at first. But then, at some point it becomes clear that being forced to keep your error conditions in mind at all times is actually a healthy thing. Then going back to languages where code may fail anywhere seems less than optimal. So…

Why not `thiserror` for executables as well? It happened to me a few times that I started to write an executable program, but then realized I want to embed its functionality in a library. Converting from `anyhow` to `thiserror` at that stage would be extra work that can be avoided.

I guess this depends somewhat on the situation. If the design is pretty clear upfront with a part that can be implemented as a core library, I'd make the library use `thiserror` from the beginning. However, if it's not really clear and I have to start with exploratory coding, then keeping track of error types that may come and go feels like unnecessary overhead, when I can just use `anyhow`.

But! To each their own!

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

#45

Post by Kaze404 »

enriquto wrote: post #33
kstenerud wrote: post #4

Error handling has been wrong since the beginning, and has continued to be wrong ever since. First, we had error codes. Except these were wrong because people forget all the time to check them. Then we had exceptions, which solved the problem of people forgetting to check by crashing the app. Then the Java team got the bright idea to have checked exceptions, which at first helped to mitigate crashes from uncaught exc…

> Error handling has been wrong since the beginning 100% this. The very concept of "error" is philosophically unsound. There are no errors; only conditions that you dislike. It is unfortunate that programming languages allow to express your emotional detachment to one of both cases of a branch. Nothing good can come from that. I yearn for a language with no error handling nor exceptions. Just plain language construct…

Isn't that what the Result type on Rust is? Sure, one of the branches is still called Error but it's just a plain language construct (a sum type you can write yourself).

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

#46

Post by [deleted] »

enriquto wrote: post #33
kstenerud wrote: post #4

Error handling has been wrong since the beginning, and has continued to be wrong ever since. First, we had error codes. Except these were wrong because people forget all the time to check them. Then we had exceptions, which solved the problem of people forgetting to check by crashing the app. Then the Java team got the bright idea to have checked exceptions, which at first helped to mitigate crashes from uncaught exc…

> Error handling has been wrong since the beginning 100% this. The very concept of "error" is philosophically unsound. There are no errors; only conditions that you dislike. It is unfortunate that programming languages allow to express your emotional detachment to one of both cases of a branch. Nothing good can come from that. I yearn for a language with no error handling nor exceptions. Just plain language construct…

[deleted]

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

#47

Post by creata »

Kaze404 wrote: post #45
enriquto wrote: post #33

Earlier quoted context omitted.

> Error handling has been wrong since the beginning 100% this. The very concept of "error" is philosophically unsound. There are no errors; only conditions that you dislike. It is unfortunate that programming languages allow to express your emotional detachment to one of both cases of a branch. Nothing good can come from that. I yearn for a language with no error handling nor exceptions. Just plain language construct…

Isn't that what the Result type on Rust is? Sure, one of the branches is still called Error but it's just a plain language construct (a sum type you can write yourself).

Yep, although I guess the Try trait[0] and the corresponding ? operator count as a special error handling language construct.

[0]: https://doc.rust-lang.org/std/ops/trait.Try.html

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

#48

Post by unrealhoang »

egnehots wrote: post #7
rklaehn wrote: post #3

Earlier quoted context omitted.

Rust error handling is great for reliable systems. But it used to be really annoying when just doing exploratory coding. With the anyhow crate, this problem is solved as well. Just use anyhow if you just want to try something out quickly without being slowed down by error type mismatches, and then later refine it to a handcrafted error type. I prefer rust error handling over all other languages I worked with (scala,…

for exploratory coding you can also just unwrap, assert, panic.. It's useful to remember that error handling is optional in those cases :)

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.

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

#49

Post by wizzwizz4 »

nwellnhof wrote: post #30
rklaehn wrote: post #3

Earlier quoted context omitted.

Rust error handling is great for reliable systems. But it used to be really annoying when just doing exploratory coding. With the anyhow crate, this problem is solved as well. Just use anyhow if you just want to try something out quickly without being slowed down by error type mismatches, and then later refine it to a handcrafted error type. I prefer rust error handling over all other languages I worked with (scala,…

> Rust error handling is great for reliable systems. Last time I checked, Rust couldn't even catch malloc failures.

To be fair, these days malloc doesn't fail; your program crashes when it tries to use the memory, and there's nothing you can do about it. (But I agree that this is a problem with Rust's alloc system.)

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

#50

Post by Zababa »

conradludgate wrote: post #25
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…

You can do something like that ``` let x = Some(1); let x = match x { Some(x) => x, None => return, }; assert_eq!(x, 1); ```

HN doesn't uses Markdown syntax for formatting: "Text after a blank line that is indented by two or more spaces is reproduced verbatim. (This is intended for code.)" https://news.ycombinator.com/formatdoc
Post reply on HN