I think Swift is close to optimal for now. It does have the union type Result<normal, error>, but most people throw/catch Error. In Swift, error is a simple v

I think Swift is close to optimal for now. It does have the union type Result<normal, error>, but most people throw/catch Error. In Swift, error is a simple value (without a stack frame) and thus is as cheap as a return value, but can be handled/caught anywhere in the call chain like an exception. Error is a protocol that tags any type, so it can carry any details you like, and your catch can switch on the type. But it's only now (10 years on) that they're declaring error types in the function signature. In this world, it turns out that not throwing is the same as throws(Never). It took this long because it's unclear (but possible) that per-type error handling helps, mainly with libraries. Serializing/tracking the originating (thread) context and avoiding merge conflicts in error streams seems like the unsolved problem. Both Java and Swift have structured concurrency with parent/child relations with derived cancellation/termination. Perhaps later that can include errors.