Hacker News Reader

Comment by lolinder | Hacker News Reader

The killer feature of Rust's Result isn't actually the monad itself, it's the ? operator. Being able to concisely say "if there's an error, bail out by returning it" gets you pretty close to exception-level convenience with just a bit more explicit syntax showing where an error might come from.

View on HN

I've not used Rust. Do you get to add context at the point of bailing?

That depends on the type you use to represent errors. A more "fancy" error type will allow you to add context / backtraces / whatever you want, while a simpler error type, for example just an error code, does not. (The error type is the E in Result<T, E>).

No, context is not added by default. With third party libraries like anyhow, it's possible to add context[0] before `?` operator in human-readable or machine-readable form:

    a_method().context("Failed to complete the work")?;
    a_method().context(FailedToCompleteTheWork)?;

[0]: https://docs.rs/anyhow/latest/anyhow/trait.Context.html

you don't want exception-style "convenience", that's the whole point

you want to be able to read code and see a single control flow

? subverts that core requirement

The problem with exceptions is that they can come from any line of code and cause a "return". Rust's question mark solves the issue because it marks which lines of code can cause a "return".

Therefore, you can always see see the control flow of a function.

Moreover, you can go even further if you really really really want a single control flow. You can write a clippy lint to disallow early returns (ban "return" keyword) and question marks. That said, I really don't think this is a good idea. The "return" keyword exists for a good reason.

? enables chaining, chaining subverts comprehensibility in exactly the ways i'm describing

All languages have chaining: that's what `;` is for. Chaining together transitions in an imperative state machine isn't simpler than chaining together `Result`s, you're just used to it.

chaining means combining a sequence of expressions that each take the same input as they give as output

; doesn't do this, afaict

when you're writing imperative code it's important that control flow (return) is explicitly visible

> chaining means combining a sequence of expressions that each take the same input as they give as output

> ; doesn't do this, afaict

It's chaining together transitions in the state machine that is your program.

> when you're writing imperative code it's important that control flow (return) is explicitly visible

Control flow is visible with `?` or other do-notation variants. If I want to error out in a `Result` context, I explicitly return `Err(bad stuff)`. And if I don't, I explicitly return `Ok(return value)` instead. If I want to introduce a new asynchronous value in js, I explicitly call `new Promise`. And so on.

What's not visible in a do-block is the implementation of control flow. Which is fine, because this isn't the code that controls it - `Ok(Err(x))` is reduced in exactly the same way no matter what `x` is or where it came from. Traditional imperative code is the same way: the runtime system always works the same way, no matter which statements you ask it to execute.

If you do choose to expose the underlying mechanisms of your control flow everywhere, you get continuation-passing style, which is useful in small doses but more or less impossible to reason about at scale.

bad:

    first()?.second()?.third()?

good:

    a = first()
    if a failed, handle that error
    b = second(a)
    if b failed, handle that error
    c = third(b)
    if c failed, handle that error
    yield c

Except that without try-catch blocks you will have n separate control flow instead of a trivial to see pattern.

huh? it's exactly the opposite

ideally, control flow goes 'down' via func calls, and 'up' via return statements

this is the "trivial to see pattern" -- the code as written

exceptions subvert those simple rules, they say any expression can potentially be a return statement, and recursively so!

And what the point to make `if err {return err}` in most of cases? I've read a lot of code and error handling logic almost never in caller location.

Reply on news.ycombinator.com