As in the caller would be forced/know what to handle in advance? Is this really the case (I'm not sure) - e.g. you call something and it returns Result<T, E> but does it really enforce it... What about errors (results) that came from deeper?

I'm not trying to defend exceptions, nor checked ones, just trying to point out that I don't think they are the same.

For all intent and purposes I really liked Common Lisp's exception handling, in my opinion the perfect one ("restartable"), but it also comes with lots of runtime efficiency (and possibly other) cost (interoperability? safety (nowadays)...) - but it was valiant effort to make programmer better - e.g. iterate while developing, and while it's throwing exceptions at you, you keep writing/updating the code (while it's running), etc - probably not something modern day SRE/devops would want (heh "who taught live updating of code of running system is great idea :)" - I still do, but I can see someone from devops frowning - "This is not the version I've pushed"...)

> but does it really enforce it

It warns you if you ignore handling a Result because the type is annotated with must_use (which can be a compile error in CI if you choose to enforce 0 warnings). Not that this is true with try/catch - no one forces you to actually do anything with the error.

> What about errors (results) that came from deeper?

Same as with exceptions - either you handle it or propagate it up or ignore it.