Page 2 of 2
Ban the error message
It's not always easy to see what to do next when an error has occurred but you can always look for a way to return the control back to the user.
After all you may not be able to implement the artificial intelligence needed but to solve the problem but you can always rely on the user to supply some intelligence. Don't ever write code that generates an error message. The worst that should ever happen is that the user should receive a polite warning that somethings didn't go according to plan and they need to think again.
Try to keep as much of the application's state intact and return to the most general form of the user interface appropriate for the state. For example, the user has just "lost" a document due to a disk or communications error. Restore all state data so that the document is still editable and return to edit mode. The user can then decide what to do. You also need to try not to constrain the user in the choice of next action so you might have to rollback some of the state - allowing the user to select a storage path or medium for example. Keep the state data but try to ensure that it can be subsequently changed.
We could go on examining examples for a long while and each example would present a different set of difficulties - but so far I've yet to find one that defeats the basic desire to "keep going". It's more an attitude of mind than something inherent in the technology.
Digital hardware might be all or nothing but the software that runs on top of it is much more flexible.
The "keep going" philosophy has at least four slogans:
- don't ever raise an exception
- always handle any exceptions that existing code beyond your control might raise
- don't ever pass exceptions on
- only ever generate warning messages - error messages are for quitters.
Of course slogans are by their very nature not binding:
- you can always make an exception.