3 ms·

Error handling patterns very much depend on the domain with possibly completely opposite recommendations, and any principles should specify in which domain it i

by jaen 1y ago

Error handling patterns very much depend on the domain with possibly completely opposite recommendations, and any principles should specify in which domain it is a good approach. Pure and deterministic algorithms can have the luxury of having much more strict and concrete error handling strategies. On the other hand, "promptly handling errors" sounds naive for large distributed systems where almost every call can fail for reasons unknown. Experience has already shown that exactly the opposite approach - just panic and restart the "service" (process in Erlang terms, but it's got nothing to do with Unix processes and is far more granular) can build extremely reliable systems. In conventional programming languages, that roughly corresponds to adding top-mid-level error boundaries (exception/panic handlers) at critical junctures. But perhaps that's what you mean by "error bubbling nests shallowly"? No idea, since it's not exactly clear.

vacuity 1y ago
I generally agree with you. I have a bad habit of simplifying my statements and losing nuance. If an error occurs, it should be handled reasonably and soon. If the cause or solution to an error is unclear, restarting at the task boundary is valid. Blowing away the whole task in one stroke is an instance of handling the error promptly. If the solution is in-task, it should be expediently reached through the call structure. Returning through many functions, performing cleanup all the while, in order to reach the handler is the pattern of deeply-nested error bubbling that I dislike. Of course, this is still a cursory description. I think various strategies by domain agree on general principles. There is likely a class of errors that is too likely and/or unsolvable, in which case whole-task-restarts are advisable. Within the task, there may be other kinds of errors that can and should reasonably be resolved. User interactivity is also relevant (e.g. is a user directly interacting with a task in the error state). Overall, this comes down to a few factors for each error, roughly: likelihood, severity, solvability. Errors should always be reported when possible and brought to the attention, if not fixed, of a capable supervisor, which eventually culimante at a person (e.g. user or sysadmin).

by jaen 1y ago

vacuity 1y ago

I generally agree with you. I have a bad habit of simplifying my statements and losing nuance. If an error occurs, it should be handled reasonably and soon. If the cause or solution to an error is unclear, restarting at the task boundary is valid. Blowing away the whole task in one stroke is an instance of handling the error promptly. If the solution is in-task, it should be expediently reached through the call structure. Returning through many functions, performing cleanup all the while, in order to reach the handler is the pattern of deeply-nested error bubbling that I dislike. Of course, this is still a cursory description. I think various strategies by domain agree on general principles. There is likely a class of errors that is too likely and/or unsolvable, in which case whole-task-restarts are advisable. Within the task, there may be other kinds of errors that can and should reasonably be resolved. User interactivity is also relevant (e.g. is a user directly interacting with a task in the error state). Overall, this comes down to a few factors for each error, roughly: likelihood, severity, solvability. Errors should always be reported when possible and brought to the attention, if not fixed, of a capable supervisor, which eventually culimante at a person (e.g. user or sysadmin).