I can't speak for Go, but what you describe isn't really a thing in Rust. Functions in Rust that might encounter an "exception" typically return something like `Result<T, E>` where `T` is the type of what we hope we get and `E` is a type that encodes the details of the errors/exceptions we might see. It's an enum type that comes in two flavors: `Ok(T)` and `Err(E)`.

You can't just go happily along treating an `E` like it's a `T`, because the compiler won't allow it. So I'm not sure how you might get into a "corrupt state". You only have three choices: panic, return and pass the error back up the call stack, or handle it explicitly. All those choices short circuit what you were doing and don't leave you with anything that you could mistake for a valid result at any level of the call stack (again, this is enforced by the compiler).

Whether it's ergonomic is another question. I happen to like it, but for sure doing exceptions in Python means fewer LOCs, if that's what you're after. I tend to be more interested in how the features of a language help programmers to keep writing correct and maintainable code as the complexity of a project grows.

I have run into something very similar in somebody else's python program where they declared a string that was later used (based on some conditionals) to locate a file. The thing is that most of the conditionals were never hit under ideal conditions (like passing all args etc.). It took me a lot of time to track down the bug (also because of the lack of awesome debuggers for Python).