If it helps I think you're right to take this approach.
In my experience defining error as 'handled' or handleable in code can often not be particularly helpful. Are the values from errno(3) always considered as handled?
EINVAL is almost always in "your" terms a fault, ENOSPC or EPIPE likely could only be handled as complete failures.
What I see too often is code which which propagates
I might push for a different set of divisions there tbh.
errno(3) is handle-able because the information exists and it is possible to use. It's the same as any other "a problem occured" signaling mechanism in that sense. Its main sin is being out-of-band of the trigger, so it's extremely easy to forget.
Whether it is handled (checked) in code is a subdivision of handle-able. Some signaling mechanisms are better about preventing not-handled than others, depending on context.
Whether you can recover from it (do something else, try again until success, etc) is also a subdivision of handle-able, and is completely unrelated to whether it was handled or not. And I think I can claim that in literally all cases the "recover-ability" is also completely unrelated to the kind of problem (ENOSPC vs EINVAL) - it only depends on what you are trying to do right now, which depends on the rest of the program and the user intent. If it was inherently unrecoverable, it wouldn't be errno(3), it'd just never return (e.g. kill your process, infinite loop, etc).
Under that framework, ENOSPC is just a normal handle-able error. It's frequently a fatal failure that is easy to forget, but it's easy to come up with something that expects and recovers from it, e.g. a lossy caching tool. Similarly, EINVAL is an unrecoverable error if you are a tool that fails on bad input, like a compiler, despite being easily recoverable in some cases (probing for feature support and gracefully degrading, perhaps).
In my experience defining error as 'handled' or handleable in code can often not be particularly helpful. Are the values from errno(3) always considered as handled?
EINVAL is almost always in "your" terms a fault, ENOSPC or EPIPE likely could only be handled as complete failures.
What I see too often is code which which propagates