In straight C, errors are a real pain. They just are. In working code, the evils of exceptions don't come up, because you don't get exceptions for the most part. As a practical matter, they're just debugging tools, and not control handlers.
This is 100% true. I was once trying to do something with POSIX semaphores on OSX and while the code compiled without so much as a peep and ran, the semaphore didn't seem to be working. Only after meticulously examining my semaphore calls and printing out the error codes was I able to discover that sem_init doesn't work on OSX. (At least this was my experience). This would have saved me hours of debugging time if the compiler spat out a warning instead.
Well, sorta. Honestly, the problem here was that your platform sucked. If sem_init() "doesn't work" on OS X (is that really true?), there's no guarantee that the putative exception-enabled version would be properly throwing an exception either. Exceptions can be really useful, but they won't fix broken libraries for you.
And it's also true that the POSIX synchronization primitives are a good example of how not to implement error handling in a C API. Too many things that are fundamentally usage errors (and should be caught at compile time) are flagged at runtime, leading to the silent failure issue you saw.
You're right, my post had less to do with exceptions and more to do with venting my frustration at the less-than-helpful C error handling system. It's not good when the API makes you think you're losing your mind.
This is 100% true. I was once trying to do something with POSIX semaphores on OSX and while the code compiled without so much as a peep and ran, the semaphore didn't seem to be working. Only after meticulously examining my semaphore calls and printing out the error codes was I able to discover that sem_init doesn't work on OSX. (At least this was my experience). This would have saved me hours of debugging time if the compiler spat out a warning instead.