There are two stinky common problems with my game, both of which annoy the hell out of me, but neither of which I can really do anything about.
The first is issues with graphics rendering. It seems that, even though OpenGL has a way to report errors like "out of memory," a lot of graphics drivers simply don't bother to do so. Instead they just render shit incorrectly and generally fuck shit up. The result is that it looks like the game sucks, but the truth is the game isn't being told anything about what's wrong. It presently doesn't pay attention other than to report the errors on stderr, but then to my knowledge, nothing useful has ever come out of OpenGL's error reporting functions, so it isn't like I'm missing out on a chance to give useful information to the user. Indeed, the graphics stacks which don't have these problems seem to deal with low memory not by reporting an error, but by swapping things to system memory where, if memory usage goes up further, the OS begins swapping out to disk. Thus the good drivers just get slower when they run low on memory, but otherwise present no errors. The bad ones just randomly drop textures and display lists, and again present no errors.
The second is issues with malloc(). Sure, malloc() will tell you when it cannot allocate memory. The problem is that there's generally nothing you can do in that case other than to terminate the program. You can't even printf() about the error because printf() uses malloc() internally and so if malloc() isn't working, printf() won't work either. Nevermind trying to do something more reasonable like display a message to the user about what went wrong and what they might be able to do about it.
Unfortunately, many of the tools programmers rely upon to make software have been written lazily, and so even if you yourself write your code to detect as many errors as possible, there are still plenty you can't do anything about. My game checks the return value of everything. In most cases it just prints a message to stdout and exits, as many errors are just so unlikely that it isn't worth the trouble of writing code to do anything else. Even so, I still get malloc() errors that don't make sense. I made it track memory usage and found that malloc() fails after allocating 400 MB of data on systems with 4 GB and no other software running. I have no clue why it's happening, and I can't do anything about it after it happens. It'd be nice if malloc() were more informative about why it is failing than to simply return NULL as a generic error. I've thought about simply doing one huge malloc() for everything I need and then write my own memory allocator to allocate out of that chunk so that I can be guaranteed to get what I need, but even that doesn't solve problems like a later printf() or some other library call failing when it calls the real malloc(), and I'd also lose out on features like realloc() being able to move memory around by asking the OS to remap pages rather than copying them.
Indeed, it would probably make a lot of sense if malloc(), like the good OpenGL stacks, simply started swapping to temporary files when it could no longer allocate more memory. Even better if it told the application about this so that it can drop things that aren't really necessary (like cached data), and so that the application can rely on the swapping to keep running as it informs the user about the problem and offers a choice to continue on at a snail's pace or to give up and terminate.
The state of error handling is really rotten all the way to the core. It isn't just individual pieces of software that suck at it. Even people who want to do it right are kind of screwed.