Exceptions?

Posted Sep 21, 2024 4:54 UTC (Sat) by zorro (subscriber, #45643)
In reply to: Exceptions? by tchernobog
Parent article: Best practices for error handling in kernel Rust

How are Rust errors conceptually different from Java checked exceptions, though? Checked exceptions force you to either handle errors as they occur, or pass them to the caller, just like Rust errors. Most people will agree that Java checked exceptions were a disaster.

I do like that panic/recover facility of Rust, it seems to match the failfast philosophy underlying robust software development very well.

to post comments

Rust Error versus Java checked exceptions

Posted Sep 21, 2024 11:16 UTC (Sat) by farnz (subscriber, #17727) [Link]

The biggest differences I've found between Rust errors and Java's checked exceptions as I experienced them in Java 1.2 days (so some of the Java issues may have been fixed in later versions) are:

It is in practice trivial to define my error type as "all errors that the functions I call can produce, plus the ones I create myself"; at one level, there's existing crates like eyre and anyhow that provide "general" error types, and at another, I can define my own error type with From implementations to convert from your error type to my error type in a meaningful fashion - which will get used by ? for bubbling the error up. In contrast, in Java, I found it very hard to define my exceptions as "the exception specification of foo, plus my added exceptions" without copying-and-pasting foo's exception specification and keeping it in sync manually.
The requirement to handle failure at the call site (even if I just use ? to immediately bubble it up to the next level up) means that it's simple to see where an error can come from; I found in Java that I'd be surprised by an exception from a function that I thought (erroneously) was infallible.

Exceptions?

Posted Oct 6, 2024 10:09 UTC (Sun) by ssokolow (guest, #94568) [Link]

Checked exceptions are a sidecar bolted onto the type system as a whole. An aftermarket verifier for a conceptually independent mechanism of control flow and data return.

Rust's error handling is just returning a value, completely within the type system. The compiler finally having support for sum types (data-bearing enums/tagged unions) as well as product types (structs and classes) is a very powerful thing... especially when paired with a little syntactic sugar like the ? operator, which more or less boils down to something like this:

let thing = match thing {
    Some(x) => x,
    Err(e) => return Err(e.into()),
}

In the error case, call whichever Into implementation matches the error side of the return type in the function signature, wrap it back up in the Err variant of the new Result type, and return it. The only thing magical about it is that the try_trait_v2 language feature hasn't been stabilized, so only the standard library can implement ? for new types in stable Rust at the moment.