>That's exactly the point. Once memory is exhausted, you can't take any action reliably. Nothing is 100% reliable, thats not realistic, and in this kind of sit

>That's exactly the point. Once memory is exhausted, you can't take any action reliably. Nothing is 100% reliable, thats not realistic, and in this kind of situation its is not a 50/50 shot, its more like 10000/1 that you will be able to show a message, that should be obvious. >It would be better to wrap your application in a script that detects when the application quit and only then shows a message to the user. Thats simpler then wrapping the specific function in a "script" that shows message to the user but allows the program to continue to function in almost all situations? >People designing things like you drive me crazy. They come up with a huge number of contingencies that just don't work in practice when push comes to shove. People like you who do not value you the user experience over pure code drive me crazy. These things actually do work in practice, I guarantee you any sufficiently complex GUI program will have code like this to try and gracefully handle as many contingencies as possible before simply crashing. Do you think your browser should just crash losing other tabs if a web site loads too much data? Does Photoshop just crash if it runs out of memory on an operation losing all your work? >Stuck in a loop trying to show a widget, using 100% of CPU and preventing me to do any action? Its no more stuck than your process crashing and the kernel is reclaiming memory, they both take similar cpu time, one however results in a message that informs you of what happens and leaves you with a running program, the other tells you nothing and your program is now gone.