An error that a programmer sees during the normal course of his work is easier to fix, and more likely to be fixed. In general, errors that are common are more likely to be fixed than errors that are rare. Therefore, use idioms that expose errors in your application. For example, if an inappropriate exception occurs, don't squelch it or (just) log it; complain loudly! Send an email to the programmers, or do something else that gets the programmers' attention.

'''Possible Techniques:'''
* FirstRuleOfLogging (inflammatory, please replace with a better link)
* DontCryWolf
* ShipWithAssertionsOn 

'''Known Uses:''' AtsProject, DenaliProject

'''Resulting Forces:''' The application may now blow up under conditions that it would ignore before. This pattern assumes that the benefit from reduced bugs outweighs the penalty of increased fragileness. However, ExceptionsCancelTransactions can help mitigate the increased fragility.

----
This pattern has been immensely successful for me. The two big projects I've run (AtsProject and DenaliProject) both used this pattern, and both had only a handful of bugs found in production. DenaliProject was an XP project, but AtsProject mostly wasn't, and didn't have UnitTest''''''s until the very end (see AtsGoesExtreme). It's hard to say for sure that ExposeErrors was the reason for their low bug count; they had a lot of other things in common as well. But I think ExposeErrors was a big part of the reason. -- JimLittle

----
I have had discussions with colleagues about what to do in the case of a serious progress-stopping error, like a database failure. I hold that it is perfectly acceptable to have the program stop, so as to clearly let the operator know that the problem is serious. Others claim that a server should never '''stop'''. I'd think that my position fits ExposeErrors. -- PeteHardie

On the AtsProject, we used root-level exception handler to display a "The database is down, contact your admin" dialog, cancel whatever action they were trying, and put them back in the screen they were on. On the DenaliProject, we displayed an "unexpected error" web page, sent the SupportSwami an email, and went back to accepting HTTP requests. This approach (ExceptionsCancelTransactions) seems to be the best of both worlds. -- JimLittle

----
Who performs the actions described at the top of the page?  Is it referring to end users, testers, managers?  ''It's referring to programmers; the program '''itself''' is supposed to expose errors. -- JimLittle''

----
This pattern has also been successful for me. We had a web application where we had big data object stored in the session, some of which was changed with each html submit. These changes were then persisted to the database. (Only the changes). To ensure that the persistence was tested thoroughly, I added a bit of code which every time a save was done, it would read the model from the database as if it was new, and compare it against the in memory object. They should always be the same. If there were any differences, it threw an exception, which was 1) logged and 2) the user got an error page.

Every morning, one of us would come in, and look at the UAT logs from the day before, and pick up on any errors that we found. Open file, search for a Persistence Exception, fix bug. The testers got really sick of seeing the error page, but we had explained what we were doing and why we did it, and they didn't mind so much. After about 2 weeks of this, we had fixed all the major problems, and the testers only occasionally got an error page.

We changed this from a specific policy to a general policy, to expose exceptions (at least in certain parts that we knew were reliable enough to cope). All exceptions are still logged (usually three or four times, actually, as they are caught by successive levels). -- MatthewFarwell

----
CategoryProtoPattern