If you're developing an application with a user interface and some terrible error occurs, it's often best to shut down the application rather than trying to continue in the face of an unknown problem and risk corrupting the data. If, however, you're writing a headless application which runs as a critical service serving many different clients, shutting down may not be the best answer. It may be best to try to recover from the error or, if it's a network or database error, to notify people that there's a problem and wait for the problem to be fixed. When you do this, you need to carefully consider and test each failure condition. If the connection to the database drops, does the code handle it nicely by occasionally trying to reconnect or does it get into a tight loop chewing up CPU time? If you lost a connection to an external system, can you reconnect later? Have you completely lost communication or is a backup channel available? Do you have to shut down the channel after a failure or will the channel come back automatically? How often should you notify somebody that there's a problem? You don't want to issue hundreds of error reports every second. These are hard issues and need to be tackled with care and with as much quality testing as you can put into it.
Download