I love reading the book Code Complete, by Steve McConnell. The following comes from it.
…

One of the paradoxes of defensive programming is that during development, you’d like an error to be noticeable-you’d rather have it to be obnoxious than risk overlooking it. But during production, you’d rather have the error to be as unobtrusive as possible, to have the program recover or fail gracefully. Here are some guidelines for deciding which defensive programming tools to leave in your production code and which to leave out:

Leave in code that checks for important errors
Decide which areas of the program can afford to have undetected errors and which areas cannot. For example, if you were writing a spreadsheet program, you could afford to have undetected errors in the screen-update area of the program because the main penalty for an error is only a messy screen. You could not afford to have undetected code in the calculation engine because such errors might result in subtly incorrect results in someone’s spreadsheet.

Remove code that checks for trivial errors
If an error has truly trivial consequences, remove code that checks for it. “Remove” doesn’t mean physically remove the code. It means use version control, precompiler switches, or some other technique to compile the program without that particular code. If space isn’t a problem, you could leave in the error-checking code but have it log messages to an error-log file unobtrusively.

Remove code that results in hard crashes
During production, your users need a chance to save their work before the program crashes and they are probably willing to tolerate a few anomalies in exchange for keeping the program going long enough for them to do that. Users don’t appreciate anything that results in the loss of their work, regardless of how much it helps debugging and ultimately improve the quality of the program. If your program contains debugging code that could cause a loss of data, take it out of the production version.

Leave in code that helps the program crash gracefully
If your program contains debugging code that detects potentially fatal errors, leave the code in that allows the program to crash gracefully. In the Mars Pathfinder, for example, engineers left some code of the debug code in by design. An error occurred after the Pathfinder had landed. By using the debug aids that had been left in, engineers at JPL were able to diagnose the problem and upload revised code to the Pathfinder, and the Pathfinder completed its mission perfectly (March 1999).

Log errors for your technical support personnel
Consider leaving debugging aids in the production code but changing their behavior so that it’s appropriate for the production version. If you’ve loaded your code with assertions that halt the program during development, you might consider changing the assertion routine to log messages to a file during production rather than eliminating them altogether.

Make sure that the error messages you leave in are friendly.
If you leave internal error messages in the program, verify that they’re in language that’s friendly to the user. A common and effective approach is to notify the user of an “internal error” and list an email address or phone number the user can use to report it.