zig gets this pretty close to "right" as per your definition. > Any error system that relies upon developer discipline will fail because errors will be missed.

zig gets this pretty close to "right" as per your definition. > Any error system that relies upon developer discipline will fail because errors will be missed. You must handle all errors on egress to either C abi or a function that does not have an error signature. > Any error system that handles all errors the same way will fail because there are some errors we can ignore, and some errors we must not ignore. And what's ignorable/retriable to one project is not ignorable/retriable to another. trys, which are the "lazy" way of error handling (not counting "catch unreachable" - which promotes errors to panics and shouldn't be used except in dev) automatically append the error return code to the trying function's error return call. > Attempting to get the complete set of error types that any given call may raise is a fool's errand because of the halting problem it eventually invokes. Forcing people to provide such a list results in the Java problem for the same reason. If every function has a well-defined tree of possible internal "call dependencies" that has finite set of type signatures, you don't have this problem.