You would think just being explicit would produce good design but what actually happened in my experience is that errors are handled by ignorance, as they get h

You would think just being explicit would produce good design but what actually happened in my experience is that errors are handled by ignorance, as they get hard to pass through. Exactly the same problem as throws clause in Java. Forcing a global (on thread or coroutine level) handler is better, as actually doing that will mean you have to structure the application in a particular way to handle anything, and that structure makes error handling actually easier. Just make it fail to compile if the correct handler is not being installed and ensure every error is identifiable. This is how hardware works anyway internally - interrupt vectors. Having a library to help with correct return and handling of error state is enough. Allowing return only to place that caused the error is saner than what C++ and Java do. There would be no temptation to pass the buck and you would have to model error state to be fully visible, enforcing it to be debuggable and part of explicit API. You could consider it syntactic salt much like Rust's memory management is.