A guide to error handling in Rust
nrc.github.io
A guide to error handling in Rust
1–10 of 76 posts
Re: A guide to error handling in Rust
#2[dead]
Re: A guide to error handling in Rust
#3try blocks? is this a bit out of date?
Re: A guide to error handling in Rust
#4try blocks? is this a bit out of date?
Nope, try blocks are a new (unstable) feature
Re: A guide to error handling in Rust
#5try blocks? is this a bit out of date?
I think you're mixing up try blocks with the old try! macro.
Re: A guide to error handling in Rust
#6try blocks? is this a bit out of date?
How so? As it says this is not yet a stable feature, but if you run nightly Rust it's available.
Try blocks let you do what ? (the Try operator) does within a block, rather than needing to split out a separate function for it, which makes sense because why should functions be special in this way?
Re: A guide to error handling in Rust
#7I feel like this document makes the Try operator (?) and its associated trait more mysterious than necessary. Most people probably won't need to implement Try, especially before it is stabilised, but it's not that much more complicated than say, AddAssign the trait which you implement to make the Add Assignment (+=) operator work on your type.
The key trick of Try is that it converts something (by default an Option or a Result or async Polls of those types) into a ControlFlow†. This is the one nice trick about Exceptions in languages which have them - they influence control flow, but Rust reified it as a vocabulary type which I think is much better. We can pass this thing back to somebody who cares about the resulting control flow, not just suddenly wrench the control flow out from under the rest of the software.
† unlike Try, ControlFlow is actually a stable type you can use today in your Rust and, like std::cmp::Ordering it's useful even just as a vocabulary type, disregarding its semantics. Library A and Library B, written by different people, in different circumstances, both agree that ControlFlow::Continue is continue and ControlFlow::Break is break whereas who knows what the boolean false from Library A means to Library B, let alone what if anything Library B's custom type BPartialResult means to Library A's code.
Re: A guide to error handling in Rust
#8Too bad Rust doesn't have union types (aka adhoc / anonymous unions) yet.
Without them, using typed errors is very clumsy. Optimally, you would write the following code:
fn foo(r1: Result, r: Result) {
let i1 = r1?;
let i2 = r2?;
// ...
}
Re: A guide to error handling in Rust
#9Too bad Rust doesn't have union types (aka adhoc / anonymous unions) yet. Without them, using typed errors is very clumsy. Optimally, you would write the following code: fn foo(r1: Result , r: Result ) { let i1 = r1?; let i2 = r2?; // ... } and Rust would infer the return type to be Result without having to do any extra definitions or conversions.
Anonymous sum types are something I want for error handling as well. In practice though I'm not sure it would really make my life that much better.
Re: A guide to error handling in Rust
#10Too bad Rust doesn't have union types (aka adhoc / anonymous unions) yet. Without them, using typed errors is very clumsy. Optimally, you would write the following code: fn foo(r1: Result , r: Result ) { let i1 = r1?; let i2 = r2?; // ... } and Rust would infer the return type to be Result without having to do any extra definitions or conversions.
Anonymous sum types are something I want for error handling as well. In practice though I'm not sure it would really make my life that much better.
It would make life a bit terser, but I’d rather have polymorphic variants. And maybe only anonymous enums over polymorphic variants.
That would make precise error handling on libraries quite a bit better.