I was particularly pleased at how well behaved WyCash was as it ran out of memory. I attribute it's good behavior to two simple rules...
Primary data was stored in a database so that all windows could be closed and no primary data lost. What was lost was calculations based on retrieved records. Calculations were performed on demand. As a user scrolled a report, cells would be exposed that would then demand a calculation and cache the result to speed subsequent scrolling.
If many large reports were opened at once, memory could be exhausted as these calculations took place. The effect was to find cells that could not be filled and therefore remained blank. The program was trying to fill the cells, but as the calculations crashed for want of memory, an error handler caught the faults and, by our rule of not interpreting uninterpretable behavior, simply printed blanks. This poor performance would, as already mentioned, lead the user to discard some less important window and then return to find the blanks could now be filled with data.
This behavior has been judged extremely reasonable by non-technical users and is much preferred to hopeless dialogs that try to explain memory requirements. The behavior was the product of AbuseCase(s) considered elsewhere in the design. -- WardCunningham
I find this fascinating. Some questions:
See TechnicalFailure