Warning: Rant ahead!
In many applications, there will be cases where something so bad happens that the application cannot continue executing reliably. In those cases, it is a good practice to fail as fast as possible to avoid compromising something critical (like corrupting the user's data). However, if you're going to fail, do so gracefully.
This means not only that you should try to fail as cleanly as possible, but that you should also make your best effort to leave clear hints of what happened that warranted such a serious action. At the very least, this will make it easier to diagnose trouble and, in doing that, it will help the poor developer maintain his sanity.
I've been working quite a bit with Windows Communication Foundation lately, and I'm using a lot one of my favourite features: Self-hosted services using the ServiceHost infrastructure. However, I do have one big gripe with it:
When you're starting your self-hosted service, you'll likelike have your configuration ready on your app.config file (though you can do so through code as well), you'll create your ServiceHost instance and then call Open() on it. During that process, ServiceHost will read your configuration and configure itself accordingly and if something is not quite right, it will fail right then and there by switching to the Faulted state and throwing an exception such as this:
System.ServiceModel.CommunicationObjectFaultedException: The communication object, System.ServiceModel.ServiceHost, cannot be used for communication because it is in the Faulted state.
What it does not do is tell you why the heck it faulted in the first place! Oh, sure, there's a Faulted event in the ServiceHost class you can attach to, and one might think initially that it would provide more information about the problem, but one would be wrong. It drives me crazy!
So, consider this a friendly suggestion for WCF v.Next (you know, 2 or 3 years from now): When there's a problem, please tell us what it is. Or include a crystal ball with the product or something.