Programs in C (and many other languages) have the problem that you can ignore errors accidentally.
Exceptions “solve” this by forcing some level of your stack to at least acknowledge that an error occurred. The problem with that model is that you still don’t have to think at any given level of the call stack what the appropriate handling is for any kind of error. You can just let it propagate up further, deferring responsibility.
For some code that might actually be appropriate, but often it results in code higher up that cannot possibly know how to deal with every error that can happen farther down the call stack just swallowing errors.
One thing I frequently see is mixing validation code with processing logic. By separating the two you can have the validation code deal with errors and the logic simply assert that it’s input is good (because it should have been validated by the error handling code before being passed in).
I think models where you are forced to think about errors at each level but have a simple mechanism to make them propagate up are probably the best single model if you have to choose one model for a language.
In any event, error handling is difficult and frequently doesn’t get the attention it deserves in the design and implementation of libraries and large systems.