Re:Where Everything Went Wrong: Error Handling and Error Mes...
by dnautics on Friday February 19, 2021 @01:01PM
(#26195883)
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.
> 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.