Report Bugs Silently is a method of TacticalTesting.
Everybody writes code so that when something bad happens, they print out an error message or they dump a stack trace or something like that. As the code matures, they handle some of those problems. When the product is about to be released, the project manager makes sure that all the printlns and stack dumps are taken out, because it sure would be embarrassing if the customer saw those. So when the program does crash on the customer, all evidence of what happened has been hidden. That's bad.
It's much safer to write the code in the first place so that the bugs are reported in a place where nobody can see them except the developers. We are lucky to have a pluggable logging system, where it's easy to configure where log messages get sent to. That way the developer can print them to the screen, and when the product is shipped they can be ferreted away in a database.
In our logging system, we have a number of severities - fatal, warning, and so on. I have invented a new one called bug. Whenever a problem of bug severity is logged, it shouldn't have, and something should be done about it. The logging system should handle KeepErrorInformation.
-- JohnFarrell
I've done something like this. Users can get into the habit of ignoring error messages if they are too frequent (of course, these are errors on another system I didn't write =) ). It's really nice when I can just look up the information that has already been sent to me on the problem, and I'm half way to solving the problem.
-- MatthewTuck
Some systems directly tell the programmer / maintainer that there is a problem, rather than relying on the user to relay that information.
A few of them pretend to be working fine -- the user hears silence.