[kaba0]

I’m talking about checked exceptions — they are absolutely analogous to a Result<ReturnType, ExceptionType> in Rust, that is they are part of the type signatures. It is no longer the example you are talking about re panics vs Result.

[littlestymaar]

Checked exceptions are indeed similar to Result, but as such they also have the same issue of “coloring” the call stack, so I don't really see what's the argument you're making here…

[kaba0]

My whole point: error handling is decided at the caller-end trivially. They can try-catch/use ?/just unwrap, whatever it doesn’t concern the implementation. Async/blocking is not like that, as it can itself recursively contain similar “decision-points”, and the final caller cares about all of them, as it might change semantics.

[littlestymaar]

But if you catch an error in the middle of the call-stack, then the caller don't have access to this error, so this has the exact same semantic implication as well! And the final caller would sometimes care about that, but no luck, yet I've never seen anyone complaining about how `catch` is terrible for that reason…

Of course it doesn't happen too often, but nor does your recursive async/blocking function example (been using async/await for a decade now, and I've never encountered the issue in actual code) and I suspect that for most purpose, using `block_on` in the blocking function is the sensible thing to do, and it has the same role as a `catch`: the upper function has no way to know there was actually some async stuff under the hood.