Exceptions are indeed not the silver bullet to error handling. Handling errors upstream can be useful as catch-all, but when the entire stack has been unwound, it can be hard to recover the error usefully. Also it is hard to make a sensible inheritance hierarchy, and every library chooses its own, generating a forest of different-but-equivalent exceptions to handle.
A fully-fledged condition system (like Smalltalk, CL) would allow for a lot of scenarios where exceptions currently give trouble. They would allow recovering the problem where it happens, retrying operations, and so on. Too bad so few languages have that.
However I don't think the right solution is to use an even more primitive language. C seems simple, but you end up doing everything yourself that would otherwise be done by the compiler, which is a lot more work, bug-prone, makes the code verbose, and generally inconsistent (unless you're very disciplined; forget about it in a team).
A fully-fledged condition system (like Smalltalk, CL) would allow for a lot of scenarios where exceptions currently give trouble. They would allow recovering the problem where it happens, retrying operations, and so on. Too bad so few languages have that.
However I don't think the right solution is to use an even more primitive language. C seems simple, but you end up doing everything yourself that would otherwise be done by the compiler, which is a lot more work, bug-prone, makes the code verbose, and generally inconsistent (unless you're very disciplined; forget about it in a team).